System Administrator's Guide

Red Hat Enterprise Linux 7

Deployment, Configuration, and Administration of Red Hat Enterprise Linux 7

Marie Doleželová

Red Hat Customer Content Services

Maxim Svistunov

Red Hat Customer Content Services

Stephen Wadeley

Red Hat Customer Content Services

Tomáš Čapek

Red Hat Customer Content Services

Jaromír Hradílek

Red Hat Customer Content Services

Douglas Silas

Red Hat Customer Content Services

Jana Heves

Red Hat Customer Content Services

Petr Kovář

Red Hat Customer Content Services

Peter Ondrejka

Red Hat Customer Content Services

Petr Bokoč

Red Hat Customer Content Services

Martin Prpič

Red Hat Product Security

Eliška Slobodová

Red Hat Customer Content Services

Eva Kopalová

Red Hat Customer Content Services

Miroslav Svoboda

Red Hat Customer Content Services

David O'Brien

Red Hat Customer Content Services

Michael Hideo

Red Hat Customer Content Services

Don Domingo

Red Hat Customer Content Services

John Ha

Red Hat Customer Content Services

Abstract

The System Administrator's Guide documents relevant information regarding the deployment, configuration, and administration of Red Hat Enterprise Linux 7. It is oriented towards system administrators with a basic understanding of the system.
If you want to use Red Hat Enterprise Linux 7 with the Linux Containers functionality, see Product Documentation for Red Hat Enterprise Linux Atomic Host. For an overview of general Linux Containers concept and their current capabilities implemented in Red Hat Enterprise Linux 7, see Overview of Containers in Red Hat Systems. The topics related to containers management and administration are described in the Red Hat Enterprise Linux Atomic Host 7 Managing Containers guide.

Part I. Basic System Configuration

This part covers basic system administration tasks such as keyboard configuration, date and time configuration, managing users and groups, and gaining privileges.

Chapter 1. System Locale and Keyboard Configuration

The system locale specifies the language settings of system services and user interfaces. The keyboard layout settings control the layout used on the text console and graphical user interfaces.
These settings can be made by modifying the /etc/locale.conf configuration file or by using the localectl utility. Also, you can use the graphical user interface to perform the task; for a description of this method, see Red Hat Enterprise Linux 7 Installation Guide.

1.1. Setting the System Locale

System-wide locale settings are stored in the /etc/locale.conf file, which is read at early boot by the systemd daemon. The locale settings configured in /etc/locale.conf are inherited by every service or user, unless individual programs or individual users override them.
The basic file format of /etc/locale.conf is a newline-separated list of variable assignments. For example, German locale with English messages in /etc/locale.conf looks as follows:
LANG=de_DE.UTF-8
LC_MESSAGES=C
Here, the LC_MESSAGES option determines the locale used for diagnostic messages written to the standard error output. To further specify locale settings in /etc/locale.conf, you can use several other options, the most relevant are summarized in Table 1.1, “Options configurable in /etc/locale.conf”. See the locale(7) manual page for detailed information on these options. Note that the LC_ALL option, which represents all possible options, should not be configured in /etc/locale.conf.

Table 1.1. Options configurable in /etc/locale.conf

OptionDescription
LANG Provides a default value for the system locale.
LC_COLLATE Changes the behavior of functions which compare strings in the local alphabet.
LC_CTYPE Changes the behavior of the character handling and classification functions and the multibyte character functions.
LC_NUMERIC Describes the way numbers are usually printed, with details such as decimal point versus decimal comma.
LC_TIME Changes the display of the current time, 24-hour versus 12-hour clock.
LC_MESSAGES Determines the locale used for diagnostic messages written to the standard error output.

1.1.1. Displaying the Current Status

The localectl command can be used to query and change the system locale and keyboard layout settings. To show the current settings, use the status option:
localectl status

Example 1.1. Displaying the Current Status

The output of the previous command lists the currently set locale, keyboard layout configured for the console and for the X11 window system.
~]$ localectl status
   System Locale: LANG=en_US.UTF-8
       VC Keymap: us
      X11 Layout: n/a

1.1.2. Listing Available Locales

To list all locales available for your system, type:
localectl list-locales

Example 1.2. Listing Locales

Imagine you want to select a specific English locale, but you are not sure if it is available on the system. You can check that by listing all English locales with the following command:
~]$ localectl list-locales | grep en_
en_AG
en_AG.utf8
en_AU
en_AU.iso88591
en_AU.utf8
en_BW
en_BW.iso88591
en_BW.utf8

output truncated

1.1.3. Setting the Locale

To set the default system locale, use the following command as root:
localectl set-locale LANG=locale
Replace locale with the locale name, found with the localectl list-locales command. The above syntax can also be used to configure parameters from Table 1.1, “Options configurable in /etc/locale.conf”.

Example 1.3. Changing the Default Locale

For example, if you want to set British English as your default locale, first find the name of this locale by using list-locales. Then, as root, type the command in the following form:
~]# localectl set-locale LANG=en_GB.utf8

1.1.4. Making System Locale Settings Permanent when Installing with Kickstart

When Red Hat Enterprise Linux is installed with the Red Hat Kickstart installation method, setting of the system locales might not be persistent after an upgrade of the operating system.
When the %packages section of the Kickstart file includes the --instLang option, the _install_langs RPM macro is set to the particular value for this installation, and the set of installed locales is adjusted accordingly. However, this adjustment affects only this installation, not subsequent upgrades. If an upgrade reinstalls the glibc package, the entire set of locales is upgraded instead of only the locales you requested during the installation.
To avoid this, make the choice of locales permanent. You have these options:

Procedure 1.1. Setting RPM macros during the Kickstart installation

  • Modify the %post section of the Kickstart file:
    LANG=en_US
    echo "%_install_langs $LANG" > /etc/rpm/macros.language-conf
    
    awk '(NF==0amp amp!done){print "override_install_langs='$LANG'";done=1}{print}' \
         < /etc/yum.conf > /etc/yum.conf.new
    mv /ec/yum.conf.new /etc/yum.conf
    

Procedure 1.2. Setting RPM macros globally

  1. Create the RPM configuration file at /etc/rpm/macros.language-conf with the following contents:
    %_install_langs LANG
    LANG is the value of the instLang option.
  2. Update the /etc/yum.conf file with:
    override_install_langs=LANG

1.2. Changing the Keyboard Layout

The keyboard layout settings enable the user to control the layout used on the text console and graphical user interfaces.

1.2.1. Displaying the Current Settings

As mentioned before, you can check your current keyboard layout configuration with the following command:
localectl status

Example 1.4. Displaying the Keyboard Settings

In the following output, you can see the keyboard layout configured for the virtual console and for the X11 window system.
~]$ localectl status
   System Locale: LANG=en_US.utf8
       VC Keymap: us
      X11 Layout: us

1.2.2. Listing Available Keymaps

To list all available keyboard layouts that can be configured on your system, type:
localectl list-keymaps

Example 1.5. Searching for a Particular Keymap

You can use grep to search the output of the previous command for a specific keymap name. There are often multiple keymaps compatible with your currently set locale. For example, to find available Czech keyboard layouts, type:
~]$ localectl list-keymaps | grep cz
cz
cz-cp1250
cz-lat2
cz-lat2-prog
cz-qwerty
cz-us-qwertz
sunt5-cz-us
sunt5-us-cz

1.2.3. Setting the Keymap

To set the default keyboard layout for your system, use the following command as root:
localectl set-keymap map
Replace map with the name of the keymap taken from the output of the localectl list-keymaps command. Unless the --no-convert option is passed, the selected setting is also applied to the default keyboard mapping of the X11 window system, after converting it to the closest matching X11 keyboard mapping. This also applies in reverse, you can specify both keymaps with the following command as root:
localectl set-x11-keymap map
If you want your X11 layout to differ from the console layout, use the --no-convert option.
localectl --no-convert set-x11-keymap map
With this option, the X11 keymap is specified without changing the previous console layout setting.

Example 1.6. Setting the X11 Keymap Separately

Imagine you want to use German keyboard layout in the graphical interface, but for console operations you want to retain the US keymap. To do so, type as root:
~]# localectl --no-convert set-x11-keymap de
Then you can verify if your setting was successful by checking the current status:
~]$ localectl status
   System Locale: LANG=de_DE.UTF-8
       VC Keymap: us
      X11 Layout: de
Apart from keyboard layout (map), three other options can be specified:
localectl set-x11-keymap map model variant options
Replace model with the keyboard model name, variant and options with keyboard variant and option components, which can be used to enhance the keyboard behavior. These options are not set by default. For more information on X11 Model, X11 Variant, and X11 Options see the kbd(4) man page.

1.3. Additional Resources

For more information on how to configure the keyboard layout on Red Hat Enterprise Linux, see the resources listed below:

Installed Documentation

  • localectl(1) — The manual page for the localectl command line utility documents how to use this tool to configure the system locale and keyboard layout.
  • loadkeys(1) — The manual page for the loadkeys command provides more information on how to use this tool to change the keyboard layout in a virtual console.

See Also

Chapter 2. Configuring the Date and Time

Modern operating systems distinguish between the following two types of clocks:
  • A real-time clock (RTC), commonly referred to as a hardware clock, (typically an integrated circuit on the system board) that is completely independent of the current state of the operating system and runs even when the computer is shut down.
  • A system clock, also known as a software clock, that is maintained by the kernel and its initial value is based on the real-time clock. Once the system is booted and the system clock is initialized, the system clock is completely independent of the real-time clock.
The system time is always kept in Coordinated Universal Time (UTC) and converted in applications to local time as needed. Local time is the actual time in your current time zone, taking into account daylight saving time (DST). The real-time clock can use either UTC or local time. UTC is recommended.
Red Hat Enterprise Linux 7 offers three command line tools that can be used to configure and display information about the system date and time: the timedatectl utility, which is new in Red Hat Enterprise Linux 7 and is part of systemd; the traditional date command; and the hwclock utility for accessing the hardware clock.

2.1. Using the timedatectl Command

The timedatectl utility is distributed as part of the systemd system and service manager and allows you to review and change the configuration of the system clock. You can use this tool to change the current date and time, set the time zone, or enable automatic synchronization of the system clock with a remote server.
For information on how to display the current date and time in a custom format, see also Section 2.2, “Using the date Command”.

2.1.1. Displaying the Current Date and Time

To display the current date and time along with detailed information about the configuration of the system and hardware clock, run the timedatectl command with no additional command line options:
timedatectl
This displays the local and universal time, the currently used time zone, the status of the Network Time Protocol (NTP) configuration, and additional information related to DST.

Example 2.1. Displaying the Current Date and Time

The following is an example output of the timedatectl command on a system that does not use NTP to synchronize the system clock with a remote server:
~]$ timedatectl
      Local time: Mon 2016-09-16 19:30:24 CEST
  Universal time: Mon 2016-09-16 17:30:24 UTC
        Timezone: Europe/Prague (CEST, +0200)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2016-03-31 01:59:59 CET
                  Sun 2016-03-31 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2016-10-27 02:59:59 CEST
                  Sun 2016-10-27 02:00:00 CET

Important

Changes to the status of chrony or ntpd will not be immediately noticed by timedatectl. If changes to the configuration or status of these tools is made, enter the following command:
~]# systemctl restart systemd-timedated.service

2.1.2. Changing the Current Time

To change the current time, type the following at a shell prompt as root:
timedatectl set-time HH:MM:SS
Replace HH with an hour, MM with a minute, and SS with a second, all typed in two-digit form.
This command updates both the system time and the hardware clock. The result it is similar to using both the date --set and hwclock --systohc commands.
The command will fail if an NTP service is enabled. See Section 2.1.5, “Synchronizing the System Clock with a Remote Server” to temporally disable the service.

Example 2.2. Changing the Current Time

To change the current time to 11:26 p.m., run the following command as root:
~]# timedatectl set-time 23:26:00
By default, the system is configured to use UTC. To configure your system to maintain the clock in the local time, run the timedatectl command with the set-local-rtc option as root:
timedatectl set-local-rtc boolean
To configure your system to maintain the clock in the local time, replace boolean with yes (or, alternatively, y, true, t, or 1). To configure the system to use UTC, replace boolean with no (or, alternatively, n, false, f, or 0). The default option is no.

2.1.3. Changing the Current Date

To change the current date, type the following at a shell prompt as root:
timedatectl set-time YYYY-MM-DD
Replace YYYY with a four-digit year, MM with a two-digit month, and DD with a two-digit day of the month.
Note that changing the date without specifying the current time results in setting the time to 00:00:00.

Example 2.3. Changing the Current Date

To change the current date to 2 June 2017 and keep the current time (11:26 p.m.), run the following command as root:
~]# timedatectl set-time 2017-06-02 23:26:00 

2.1.4. Changing the Time Zone

To list all available time zones, type the following at a shell prompt:
timedatectl list-timezones
To change the currently used time zone, type as root:
timedatectl set-timezone time_zone
Replace time_zone with any of the values listed by the timedatectl list-timezones command.

Example 2.4. Changing the Time Zone

To identify which time zone is closest to your present location, use the timedatectl command with the list-timezones command line option. For example, to list all available time zones in Europe, type:
~]# timedatectl list-timezones | grep Europe
Europe/Amsterdam
Europe/Andorra
Europe/Athens
Europe/Belgrade
Europe/Berlin
Europe/Bratislava
To change the time zone to Europe/Prague, type as root:
~]# timedatectl set-timezone Europe/Prague

2.1.5. Synchronizing the System Clock with a Remote Server

As opposed to the manual adjustments described in the previous sections, the timedatectl command also allows you to enable automatic synchronization of your system clock with a group of remote servers using the NTP protocol. Enabling NTP enables the chronyd or ntpd service, depending on which of them is installed.
The NTP service can be enabled and disabled using a command as follows:
timedatectl set-ntp boolean
To enable your system to synchronize the system clock with a remote NTP server, replace boolean with yes (the default option). To disable this feature, replace boolean with no.

Example 2.5. Synchronizing the System Clock with a Remote Server

To enable automatic synchronization of the system clock with a remote server, type:
~]# timedatectl set-ntp yes
The command will fail if an NTP service is not installed. See Section 16.3.1, “Installing chrony” for more information.

2.2. Using the date Command

The date utility is available on all Linux systems and allows you to display and configure the current date and time. It is frequently used in scripts to display detailed information about the system clock in a custom format.
For information on how to change the time zone or enable automatic synchronization of the system clock with a remote server, see Section 2.1, “Using the timedatectl Command”.

2.2.1. Displaying the Current Date and Time

To display the current date and time, run the date command with no additional command line options:
date
This displays the day of the week followed by the current date, local time, abbreviated time zone, and year.
By default, the date command displays the local time. To display the time in UTC, run the command with the --utc or -u command line option:
date --utc
You can also customize the format of the displayed information by providing the +"format" option on the command line:
date +"format"
Replace format with one or more supported control sequences as illustrated in Example 2.6, “Displaying the Current Date and Time”. See Table 2.1, “Commonly Used Control Sequences” for a list of the most frequently used formatting options, or the date(1) manual page for a complete list of these options.

Table 2.1. Commonly Used Control Sequences

Control SequenceDescription
%H The hour in the HH format (for example, 17).
%M The minute in the MM format (for example, 30).
%S The second in the SS format (for example, 24).
%d The day of the month in the DD format (for example, 16).
%m The month in the MM format (for example, 09).
%Y The year in the YYYY format (for example, 2016).
%Z The time zone abbreviation (for example, CEST).
%F The full date in the YYYY-MM-DD format (for example, 2016-09-16). This option is equal to %Y-%m-%d.
%T The full time in the HH:MM:SS format (for example, 17:30:24). This option is equal to %H:%M:%S

Example 2.6. Displaying the Current Date and Time

To display the current date and local time, type the following at a shell prompt:
~]$ date
Mon Sep 16 17:30:24 CEST 2016
To display the current date and time in UTC, type the following at a shell prompt:
~]$ date --utc
Mon Sep 16 15:30:34 UTC 2016
To customize the output of the date command, type:
~]$ date +"%Y-%m-%d %H:%M"
2016-09-16 17:30

2.2.2. Changing the Current Time

To change the current time, run the date command with the --set or -s option as root:
date --set HH:MM:SS
Replace HH with an hour, MM with a minute, and SS with a second, all typed in two-digit form.
By default, the date command sets the system clock to the local time. To set the system clock in UTC, run the command with the --utc or -u command line option:
date --set HH:MM:SS --utc

Example 2.7. Changing the Current Time

To change the current time to 11:26 p.m., run the following command as root:
~]# date --set 23:26:00

2.2.3. Changing the Current Date

To change the current date, run the date command with the --set or -s option as root:
date --set YYYY-MM-DD
Replace YYYY with a four-digit year, MM with a two-digit month, and DD with a two-digit day of the month.
Note that changing the date without specifying the current time results in setting the time to 00:00:00.

Example 2.8. Changing the Current Date

To change the current date to 2 June 2017 and keep the current time (11:26 p.m.), run the following command as root:
~]# date --set "2017-06-02 23:26:00"

2.3. Using the hwclock Command

hwclock is a utility for accessing the hardware clock, also referred to as the Real Time Clock (RTC). The hardware clock is independent of the operating system you use and works even when the machine is shut down. This utility is used for displaying the time from the hardware clock. hwclock also contains facilities for compensating for systematic drift in the hardware clock.
The hardware clock stores the values of: year, month, day, hour, minute, and second. It is not able to store the time standard, local time or Coordinated Universal Time (UTC), nor set the Daylight Saving Time (DST).
The hwclock utility saves its settings in the /etc/adjtime file, which is created with the first change you make, for example, when you set the time manually or synchronize the hardware clock with the system time.

Note

In Red Hat Enterprise Linux 6, the hwclock command was run automatically on every system shutdown or reboot, but it is not in Red Hat Enterprise Linux 7. When the system clock is synchronized by the Network Time Protocol (NTP) or Precision Time Protocol (PTP), the kernel automatically synchronizes the hardware clock to the system clock every 11 minutes.
For details about NTP, see Chapter 16, Configuring NTP Using the chrony Suite and Chapter 17, Configuring NTP Using ntpd. For information about PTP, see Chapter 18, Configuring PTP Using ptp4l. For information about setting the hardware clock after executing ntpdate, see Section 17.18, “Configuring the Hardware Clock Update”.

2.3.1. Displaying the Current Date and Time

Running hwclock with no command line options as the root user returns the date and time in local time to standard output.
hwclock
Note that using the --utc or --localtime options with the hwclock command does not mean you are displaying the hardware clock time in UTC or local time. These options are used for setting the hardware clock to keep time in either of them. The time is always displayed in local time. Additionally, using the hwclock --utc or hwclock --local commands does not change the record in the /etc/adjtime file. This command can be useful when you know that the setting saved in /etc/adjtime is incorrect but you do not want to change the setting. On the other hand, you may receive misleading information if you use the command an incorrect way. See the hwclock(8) manual page for more details.

Example 2.9. Displaying the Current Date and Time

To display the current date and the current local time from the hardware clock, run as root:
~]# hwclock
Tue 15 Apr 2017 04:23:46 PM CEST     -0.329272 seconds
CEST is a time zone abbreviation and stands for Central European Summer Time.
For information on how to change the time zone, see Section 2.1.4, “Changing the Time Zone”.

2.3.2. Setting the Date and Time

Besides displaying the date and time, you can manually set the hardware clock to a specific time.
When you need to change the hardware clock date and time, you can do so by appending the --set and --date options along with your specification:
hwclock --set --date "dd mmm yyyy HH:MM"
Replace dd with a day (a two-digit number), mmm with a month (a three-letter abbreviation), yyyy with a year (a four-digit number), HH with an hour (a two-digit number), MM with a minute (a two-digit number).
At the same time, you can also set the hardware clock to keep the time in either UTC or local time by adding the --utc or --localtime options, respectively. In this case, UTC or LOCAL is recorded in the /etc/adjtime file.

Example 2.10. Setting the Hardware Clock to a Specific Date and Time

If you want to set the date and time to a specific value, for example, to "21:17, October 21, 2016", and keep the hardware clock in UTC, run the command as root in the following format:
~]# hwclock --set --date "21 Oct 2016 21:17" --utc

2.3.3. Synchronizing the Date and Time

You can synchronize the hardware clock and the current system time in both directions.
  • Either you can set the hardware clock to the current system time by using this command:
    hwclock --systohc
    Note that if you use NTP, the hardware clock is automatically synchronized to the system clock every 11 minutes, and this command is useful only at boot time to get a reasonable initial system time.
  • Or, you can set the system time from the hardware clock by using the following command:
    hwclock --hctosys
When you synchronize the hardware clock and the system time, you can also specify whether you want to keep the hardware clock in local time or UTC by adding the --utc or --localtime option. Similarly to using --set, UTC or LOCAL is recorded in the /etc/adjtime file.
The hwclock --systohc --utc command is functionally similar to timedatectl set-local-rtc false and the hwclock --systohc --local command is an alternative to timedatectl set-local-rtc true.

Example 2.11. Synchronizing the Hardware Clock with System Time

To set the hardware clock to the current system time and keep the hardware clock in local time, run the following command as root:
~]# hwclock --systohc --localtime
To avoid problems with time zone and DST switching, it is recommended to keep the hardware clock in UTC. The shown Example 2.11, “Synchronizing the Hardware Clock with System Time” is useful, for example, in case of a multi boot with a Windows system, which assumes the hardware clock runs in local time by default, and all other systems need to accommodate to it by using local time as well. It may also be needed with a virtual machine; if the virtual hardware clock provided by the host is running in local time, the guest system needs to be configured to use local time, too.

2.4. Additional Resources

For more information on how to configure the date and time in Red Hat Enterprise Linux 7, see the resources listed below.

Installed Documentation

  • timedatectl(1) — The manual page for the timedatectl command line utility documents how to use this tool to query and change the system clock and its settings.
  • date(1) — The manual page for the date command provides a complete list of supported command line options.
  • hwclock(8) — The manual page for the hwclock command provides a complete list of supported command line options.

See Also

Chapter 3. Managing Users and Groups

The control of users and groups is a core element of Red Hat Enterprise Linux system administration. This chapter explains how to add, manage, and delete users and groups in the graphical user interface and on the command line, and covers advanced topics, such as creating group directories.

3.1. Introduction to Users and Groups

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. For more information about this feature, see Chapter 4, Access Control Lists.

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 IDs starting at 5,000 that were not already reserved, 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. See Section 3.3.5, “Setting Default Permissions for New Files Using umask for more information.
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/shadow file, some utilities and commands do not work without first enabling shadow passwords:
  • The chage utility for setting password aging parameters. For details, see the Password Security section in the Red Hat Enterprise Linux 7 Security Guide.
  • 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.

3.2. Managing Users in a Graphical Environment

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 Space bar. 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.
The Users Settings Tool

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.
The Password Menu

Figure 3.2. The Password Menu

3.3. Using Command-Line Tools

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. See the Password Security section in the Red Hat Enterprise Linux 7 Security Guide.

Table 3.2. Common useradd command-line options

Option
-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.

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 user name 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, see Section 3.1.1, “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 (see the Password Security section in the Red Hat Enterprise Linux 7 Security Guide for details).

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. Adding an Existing User to an Existing Group

Use the usermod utility to add an already existing user to an already existing group.
Various options of usermod have different impact on user's primary group and on his or her supplementary groups.
To override user's primary group, run the following command as root:
~]# usermod -g group_name user_name
To override user's supplementary groups, run the following command as root:
~]# usermod -G group_name1,group_name2,... user_name
Note that in this case all previous supplementary groups of the user are replaced by the new group or several new groups.
To add one or more groups to user's supplementary groups, run one of the following commands as root:
~]# usermod -aG group_name1,group_name2,... user_name
~]# usermod --append -G group_name1,group_name2,... user_name
Note that in this case the new group is added to user's current supplementary groups.

3.3.4. 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.5. 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.
Applying umask when creating a 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.5.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 umaskfor 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

3.4. Additional Resources

For more information on how to manage users and groups on Red Hat Enterprise Linux, see the resources listed below.

Installed Documentation

For information about various utilities for managing users and groups, see the following manual pages:
  • useradd(8) — The manual page for the useradd command documents how to use it to create new users.
  • userdel(8) — The manual page for the userdel command documents how to use it to delete users.
  • usermod(8) — The manual page for the usermod command documents how to use it to modify users.
  • groupadd(8) — The manual page for the groupadd command documents how to use it to create new groups.
  • groupdel(8) — The manual page for the groupdel command documents how to use it to delete groups.
  • groupmod(8) — The manual page for the groupmod command documents how to use it to modify group membership.
  • gpasswd(1) — The manual page for the gpasswd command documents how to manage the /etc/group file.
  • grpck(8) — The manual page for the grpck command documents how to use it to verify the integrity of the /etc/group file.
  • pwck(8) — The manual page for the pwck command documents how to use it to verify the integrity of the /etc/passwd and /etc/shadow files.
  • pwconv(8) — The manual page for the pwconv, pwunconv, grpconv, and grpunconv commands documents how to convert shadowed information for passwords and groups.
  • id(1) — The manual page for the id command documents how to display user and group IDs.
  • umask(2) — The manual page for the umask command documents how to work with the file mode creation mask.
For information about related configuration files, see:
  • group(5) — The manual page for the /etc/group file documents how to use this file to define system groups.
  • passwd(5) — The manual page for the /etc/passwd file documents how to use this file to define user information.
  • shadow(5) — The manual page for the /etc/shadow file documents how to use this file to set passwords and account expiration information for the system.

Online Documentation

  • Red Hat Enterprise Linux 7 Security Guide — The Security Guide for Red Hat Enterprise Linux 7 provides additional information how to ensure password security and secure the workstation by enabling password aging and user account locking.

See Also

Chapter 4. Access Control Lists

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.

4.2. Setting Access ACLs

There are two types of ACLs: access ACLs and default ACLs. An access ACL is the access control list for a specific file or directory. A default ACL can only be associated with a directory; if a file within the directory does not have an access ACL, it uses the rules of the default ACL for the directory. Default ACLs are optional.
ACLs can be configured:
  1. Per user
  2. Per group
  3. Via the effective rights mask
  4. For users not in the user group for the file
The setfacl utility sets ACLs for files and directories. Use the -m option to add or modify the ACL of a file or directory:
# setfacl -m rules files
Rules (rules) must be specified in the following formats. Multiple rules can be specified in the same command if they are separated by commas.
u:uid:perms
Sets the access ACL for a user. The user name or UID may be specified. The user may be any valid user on the system.
g:gid:perms
Sets the access ACL for a group. The group name or GID may be specified. The group may be any valid group on the system.
m:perms
Sets the effective rights mask. The mask is the union of all permissions of the owning group and all of the user and group entries.
o:perms
Sets the access ACL for users other than the ones in the group for the file.
Permissions (perms) must be a combination of the characters r, w, and x for read, write, and execute.
If a file or directory already has an ACL, and the setfacl command is used, the additional rules are added to the existing ACL or the existing rule is modified.

Example 4.1. Give read and write permissions

For example, to give read and write permissions to user andrius:
# setfacl -m u:andrius:rw /project/somefile
To remove all the permissions for a user, group, or others, use the -x option and do not specify any permissions:
# setfacl -x rules files

Example 4.2. Remove all permissions

For example, to remove all permissions from the user with UID 500:
# setfacl -x u:500 /project/somefile

4.3. Setting Default ACLs

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

4.4. Retrieving ACLs

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

4.5. Archiving File Systems With ACLs

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.

4.6. Compatibility with Older Systems

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.

4.7. ACL References

Refer to the following man pages for more information.
  • man acl — Description of ACLs
  • man getfacl — Discusses how to get file access control lists
  • man setfacl — Explains how to set file access control lists
  • man star — Explains more about the star utility and its many options

Chapter 5. Gaining Privileges

System administrators, and in some cases users, need to perform certain tasks with administrative access. Accessing the system as the root user is potentially dangerous and can lead to widespread damage to the system and data. This chapter covers ways to gain administrative privileges using the setuid programs such as su and sudo. These programs allow specific users to perform tasks which would normally be available only to the root user while maintaining a higher level of control and system security.
See the Red Hat Enterprise Linux 7 Security Guide for more information on administrative controls, potential dangers and ways to prevent data loss resulting from improper use of privileged access.

5.1. The su Command

When a user executes the su command, they are prompted for the root password and, after authentication, are given a root shell prompt.
Once logged in using the su command, the user is the root user and has absolute administrative access to the system. Note that this access is still subject to the restrictions imposed by SELinux, if it is enabled. In addition, once a user has become root, it is possible for them to use the su command to change to any other user on the system without being prompted for a password.
Because this program is so powerful, administrators within an organization may want to limit who has access to the command.
One of the simplest ways to do this is to add users to the special administrative group called wheel. To do this, type the following command as root:
~]# usermod -a -G wheel username
In the previous command, replace username with the user name you want to add to the wheel group.
You can also use the Users settings tool to modify group memberships, as follows. Note that you need administrator privileges to perform this procedure.
  1. 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.
  2. To enable making changes, click the Unlock button, and enter a valid administrator password.
  3. Click a user icon in the left column to display the user's properties in the right pane.
  4. Change the Account Type from Standard to Administrator. This will add the user to the wheel group.
See Section 3.2, “Managing Users in a Graphical Environment” for more information about the Users tool.
After you add the desired users to the wheel group, it is advisable to only allow these specific users to use the su command. To do this, edit the Pluggable Authentication Module (PAM) configuration file for su, /etc/pam.d/su. Open this file in a text editor and uncomment the following line by removing the # character:
#auth           required        pam_wheel.so use_uid
This change means that only members of the administrative group wheel can switch to another user using the su command.

Note

The root user is part of the wheel group by default.

5.2. The sudo Command

The sudo command offers another approach to giving users administrative access. When trusted users precede an administrative command with sudo, they are prompted for their own password. Then, when they have been authenticated and assuming that the command is permitted, the administrative command is executed as if they were the root user.
The basic format of the sudo command is as follows:
sudo command
In the above example, command would be replaced by a command normally reserved for the root user, such as mount.
The sudo command allows for a high degree of flexibility. For instance, only users listed in the /etc/sudoers configuration file are allowed to use the sudo command and the command is executed in the user's shell, not a root shell. This means the root shell can be completely disabled as shown in the Red Hat Enterprise Linux 7 Security Guide.
Each successful authentication using the sudo command is logged to the file /var/log/messages and the command issued along with the issuer's user name is logged to the file /var/log/secure. If additional logging is required, use the pam_tty_audit module to enable TTY auditing for specified users by adding the following line to your /etc/pam.d/system-auth file:
session required pam_tty_audit.so disable=pattern enable=pattern
where pattern represents a comma-separated listing of users with an optional use of globs. For example, the following configuration will enable TTY auditing for the root user and disable it for all other users:
session required pam_tty_audit.so disable=* enable=root

Important

Configuring the pam_tty_audit PAM module for TTY auditing records only TTY input. This means that, when the audited user logs in, pam_tty_audit records the exact keystrokes the user makes into the /var/log/audit/audit.log file. For more information, see the pam_tty_audit(8) manual page.
Another advantage of the sudo command is that an administrator can allow different users access to specific commands based on their needs.
Administrators wanting to edit the sudo configuration file, /etc/sudoers, should use the visudo command.
To give someone full administrative privileges, type visudo and add a line similar to the following in the user privilege specification section:
juan ALL=(ALL) ALL
This example states that the user, juan, can use sudo from any host and execute any command.
The example below illustrates the granularity possible when configuring sudo:
%users localhost=/usr/sbin/shutdown -h now
This example states that any member of the users system group can issue the command /sbin/shutdown -h now as long as it is issued from the console.
The man page for sudoers has a detailed listing of options for this file.

Important

There are several potential risks to keep in mind when using the sudo command. You can avoid them by editing the /etc/sudoers configuration file using visudo as described above. Leaving the /etc/sudoers file in its default state gives every user in the wheel group unlimited root access.
  • By default, sudo stores the password for a five minute timeout period. Any subsequent uses of the command during this period will not prompt the user for a password. This could be exploited by an attacker if the user leaves his workstation unattended and unlocked while still being logged in. This behavior can be changed by adding the following line to the /etc/sudoers file:
    Defaults    timestamp_timeout=value
    where value is the desired timeout length in minutes. Setting the value to 0 causes sudo to require a password every time.
  • If an account is compromised, an attacker can use sudo to open a new shell with administrative privileges:
    sudo /bin/bash
    Opening a new shell as root in this or similar fashion gives the attacker administrative access for a theoretically unlimited amount of time, bypassing the timeout period specified in the /etc/sudoers file and never requiring the attacker to input a password for sudo again until the newly opened session is closed.

5.3. Additional Resources

While programs allowing users to gain administrative privileges are a potential security risk, security itself is beyond the scope of this particular book. You should therefore refer to the resources listed below for more information regarding security and privileged access.

Installed Documentation

  • su(1) — The manual page for su provides information regarding the options available with this command.
  • sudo(8) — The manual page for sudo includes a detailed description of this command and lists options available for customizing its behavior.
  • pam(8) — The manual page describing the use of Pluggable Authentication Modules (PAM) for Linux.

Online Documentation

  • Red Hat Enterprise Linux 7 Security Guide — The Security Guide for Red Hat Enterprise Linux 7 provides a more detailed look at potential security issues pertaining to the setuid programs as well as techniques used to alleviate these risks.

See Also

Part II. Subscription and Support

To receive updates to the software on a Red Hat Enterprise Linux system it must be subscribed to the Red Hat Content Delivery Network (CDN) and the appropriate repositories enabled. This part describes how to subscribe a system to the Red Hat Content Delivery Network.
Red Hat provides support via the Customer Portal, and you can access this support directly from the command line using the Red Hat Support Tool. This part describes the use of this command-line tool.

Chapter 6. Registering the System and Managing Subscriptions

The subscription service provides a mechanism to handle Red Hat software inventory and allows you to install additional software or update already installed programs to newer versions using the yum package manager. In Red Hat Enterprise Linux 7 the recommended way to register your system and attach subscriptions is to use Red Hat Subscription Management.

Note

It is also possible to register the system and attach subscriptions after installation during the initial setup process. For detailed information about the initial setup see the Initial Setup chapter in the Installation Guide for Red Hat Enterprise Linux 7. Note that the Initial Setup application is only available on systems installed with the X Window System at the time of installation.

6.1. Registering the System and Attaching Subscriptions

Complete the following steps to register your system and attach one or more subscriptions using Red Hat Subscription Management. Note that all subscription-manager commands are supposed to be run as root.
  1. Run the following command to register your system. You will be prompted to enter your user name and password. Note that the user name and password are the same as your login credentials for Red Hat Customer Portal.
    subscription-manager register
  2. Determine the pool ID of a subscription that you require. To do so, type the following at a shell prompt to display a list of all subscriptions that are available for your system:
    subscription-manager list --available
    For each available subscription, this command displays its name, unique identifier, expiration date, and other details related to your subscription. To list subscriptions for all architectures, add the --all option. The pool ID is listed on a line beginning with Pool ID.
  3. Attach the appropriate subscription to your system by entering a command as follows:
    subscription-manager attach --pool=pool_id
    Replace pool_id with the pool ID you determined in the previous step.
    To verify the list of subscriptions your system has currently attached, at any time, run:
    subscription-manager list --consumed
For more details on how to register your system using Red Hat Subscription Management and associate it with subscriptions, see the designated solution article. For comprehensive information about subscriptions, see the Red Hat Subscription Management collection of guides.

6.2. Managing Software Repositories

When a system is subscribed to the Red Hat Content Delivery Network, a repository file is created in the /etc/yum.repos.d/ directory. To verify that, use yum to list all enabled repositories:
yum repolist
Red Hat Subscription Management also allows you to manually enable or disable software repositories provided by Red Hat. To list all available repositories, use the following command:
subscription-manager repos --list
The repository names depend on the specific version of Red Hat Enterprise Linux you are using and are in the following format:
rhel-variant-rhscl-version-rpms
rhel-variant-rhscl-version-debug-rpms
rhel-variant-rhscl-version-source-rpms
Where variant is the Red Hat Enterprise Linux system variant (server or workstation), and version is the Red Hat Enterprise Linux system version (6 or 7), for example:
rhel-server-rhscl-7-eus-rpms
rhel-server-rhscl-7-eus-source-rpms
rhel-server-rhscl-7-eus-debug-rpms
To enable a repository, enter a command as follows:
subscription-manager repos --enable repository
Replace repository with a name of the repository to enable.
Similarly, to disable a repository, use the following command:
subscription-manager repos --disable repository
Section 8.5, “Configuring Yum and Yum Repositories” provides detailed information about managing software repositories using yum.

6.3. Removing Subscriptions

To remove a particular subscription, complete the following steps.
  1. Determine the serial number of the subscription you want to remove by listing information about already attached subscriptions:
    subscription-manager list --consumed
    The serial number is the number listed as serial. For instance, 744993814251016831 in the example below:
    SKU:               ES0113909
    Contract:          01234567
    Account:           1234567
    Serial:            744993814251016831
    Pool ID:           8a85f9894bba16dc014bccdd905a5e23
    Active:            False
    Quantity Used:     1
    Service Level:     SELF-SUPPORT
    Service Type:      L1-L3
    Status Details:    
    Subscription Type: Standard
    Starts:            02/27/2015
    Ends:              02/27/2016
    System Type:       Virtual
  2. Enter a command as follows to remove the selected subscription:
    subscription-manager remove --serial=serial_number
    Replace serial_number with the serial number you determined in the previous step.
To remove all subscriptions attached to the system, run the following command:
subscription-manager remove --all

6.4. Additional Resources

For more information on how to register your system using Red Hat Subscription Management and associate it with subscriptions, see the resources listed below.

Installed Documentation

  • subscription-manager(8) — the manual page for Red Hat Subscription Management provides a complete list of supported options and commands.

See Also

Chapter 7. Accessing Support Using the Red Hat Support Tool

The Red Hat Support Tool, in the redhat-support-tool package, can function as both an interactive shell and as a single-execution program. It can be run over SSH or from any terminal. It enables, for example, searching the Red Hat Knowledgebase from the command line, copying solutions directly on the command line, opening and updating support cases, and sending files to Red Hat for analysis.

7.1. Installing the Red Hat Support Tool

The Red Hat Support Tool is installed by default on Red Hat Enterprise Linux. If required, to ensure that it is, enter the following command as root:
~]# yum install redhat-support-tool

7.2. Registering the Red Hat Support Tool Using the Command Line

To register the Red Hat Support Tool to the customer portal using the command line, proceed as follows:
  1. ~]# redhat-support-tool config user username
    Where username is the user name of the Red Hat Customer Portal account.
  2. ~]# redhat-support-tool config password
    Please enter the password for username:

7.3. Using the Red Hat Support Tool in Interactive Shell Mode

To start the tool in interactive mode, enter the following command:
~]$ redhat-support-tool
Welcome to the Red Hat Support Tool.
Command (? for help):
The tool can be run as an unprivileged user, with a consequently reduced set of commands, or as root.
The commands can be listed by entering the ? character. The program or menu selection can be exited by entering the q or e character. You will be prompted for your Red Hat Customer Portal user name and password when you first search the Knowledgebase or support cases. Alternately, set the user name and password for your Red Hat Customer Portal account using interactive mode, and optionally save it to the configuration file.

7.4. Configuring the Red Hat Support Tool

When in interactive mode, the configuration options can be listed by entering the command config --help:
~]# redhat-support-tool
Welcome to the Red Hat Support Tool.
Command (? for help): config --help

Usage: config [options] config.option <new option value>

Use the 'config' command to set or get configuration file values.
Options:
  -h, --help    show this help message and exit
  -g, --global  Save configuration option in /etc/redhat-support-tool.conf.
  -u, --unset   Unset configuration option.

The configuration file options which can be set are:
 user      : The Red Hat Customer Portal user.
 password  : The Red Hat Customer Portal password.
 debug     : CRITICAL, ERROR, WARNING, INFO, or DEBUG
 url       : The support services URL.  Default=https://api.access.redhat.com
 proxy_url : A proxy server URL.
 proxy_user: A proxy server user.
 proxy_password: A password for the proxy server user.
 ssl_ca    : Path to certificate authorities to trust during communication.
 kern_debug_dir: Path to the directory where kernel debug symbols should be downloaded and cached. Default=/var/lib/redhat-support-tool/debugkernels

Examples:
- config user
- config user my-rhn-username
- config --unset user

Procedure 7.1. Registering the Red Hat Support Tool Using Interactive Mode

To register the Red Hat Support Tool to the customer portal using interactive mode, proceed as follows:
  1. Start the tool by entering the following command:
    ~]# redhat-support-tool
  2. Enter your Red Hat Customer Portal user name:
    Command (? for help): config user username
    To save your user name to the global configuration file, add the -g option.
  3. Enter your Red Hat Customer Portal password:
    Command (? for help): config password
    Please enter the password for username:

7.4.1. Saving Settings to the Configuration Files

The Red Hat Support Tool, unless otherwise directed, stores values and options locally in the home directory of the current user, using the ~/.redhat-support-tool/redhat-support-tool.conf configuration file. If required, it is recommended to save passwords to this file because it is only readable by that particular user. When the tool starts, it will read values from the global configuration file /etc/redhat-support-tool.conf and from the local configuration file. Locally stored values and options take precedence over globally stored settings.

Warning

It is recommended not to save passwords in the global /etc/redhat-support-tool.conf configuration file because the password is just base64 encoded and can easily be decoded. In addition, the file is world readable.
To save a value or option to the global configuration file, add the -g, --global option as follows:
Command (? for help): config setting -g value

Note

In order to be able to save settings globally, using the -g, --global option, the Red Hat Support Tool must be run as root because normal users do not have the permissions required to write to /etc/redhat-support-tool.conf.
To remove a value or option from the local configuration file, add the -u, --unset option as follows:
Command (? for help): config setting -u value
This will clear, unset, the parameter from the tool and fall back to the equivalent setting in the global configuration file, if available.

Note

When running as an unprivileged user, values stored in the global configuration file cannot be removed using the -u, --unset option, but they can be cleared, unset, from the current running instance of the tool by using the -g, --global option simultaneously with the -u, --unset option. If running as root, values and options can be removed from the global configuration file using -g, --global simultaneously with the -u, --unset option.

7.5. Opening and Updating Support Cases Using Interactive Mode

Procedure 7.2. Opening a New Support Case Using Interactive Mode

To open a new support case using interactive mode, proceed as follows:
  1. Start the tool by entering the following command:
    ~]# redhat-support-tool
  2. Enter the opencase command:
    Command (? for help): opencase
  3. Follow the on screen prompts to select a product and then a version.
  4. Enter a summary of the case.
  5. Enter a description of the case and press Ctrl+D on an empty line when complete.
  6. Select a severity of the case.
  7. Optionally chose to see if there is a solution to this problem before opening a support case.
  8. Confirm you would still like to open the support case.
    Support case 0123456789 has successfully been opened
  9. Optionally chose to attach an SOS report.
  10. Optionally chose to attach a file.

Procedure 7.3. Viewing and Updating an Existing Support Case Using Interactive Mode

To view and update an existing support case using interactive mode, proceed as follows:
  1. Start the tool by entering the following command:
    ~]# redhat-support-tool
  2. Enter the getcase command:
    Command (? for help): getcase case-number
    Where case-number is the number of the case you want to view and update.
  3. Follow the on screen prompts to view the case, modify or add comments, and get or add attachments.

Procedure 7.4. Modifying an Existing Support Case Using Interactive Mode

To modify the attributes of an existing support case using interactive mode, proceed as follows:
  1. Start the tool by entering the following command:
    ~]# redhat-support-tool
  2. Enter the modifycase command:
    Command (? for help): modifycase case-number
    Where case-number is the number of the case you want to view and update.
  3. The modify selection list appears:
    Type the number of the attribute to modify or 'e' to return to the previous menu.
     1 Modify Type
     2 Modify Severity
     3 Modify Status
     4 Modify Alternative-ID
     5 Modify Product
     6 Modify Version
    End of options.
    Follow the on screen prompts to modify one or more of the options.
  4. For example, to modify the status, enter 3:
    Selection: 3
     1   Waiting on Customer                                                        
     2   Waiting on Red Hat                                                         
     3   Closed                                                                     
    Please select a status (or 'q' to exit):

7.6. Viewing Support Cases on the Command Line

Viewing the contents of a case on the command line provides a quick and easy way to apply solutions from the command line.
To view an existing support case on the command line, enter a command as follows:
~]# redhat-support-tool getcase case-number
Where case-number is the number of the case you want to download.

7.7. Additional Resources

The Red Hat Knowledgebase article Red Hat Support Tool has additional information, examples, and video tutorials.

Part III. Installing and Managing Software

All software on a Red Hat Enterprise Linux system is divided into RPM packages, which can be installed, upgraded, or removed. This part describes how to manage packages on Red Hat Enterprise Linux using Yum.

Chapter 8. Yum

Yum is the Red Hat package manager that is able to query for information about available packages, fetch packages from repositories, install and uninstall them, and update an entire system to the latest available version. Yum performs automatic dependency resolution when updating, installing, or removing packages, and thus is able to automatically determine, fetch, and install all available dependent packages.
Yum can be configured with new, additional repositories, or package sources, and also provides many plug-ins which enhance and extend its capabilities. Yum is able to perform many of the same tasks that RPM can; additionally, many of the command-line options are similar. Yum enables easy and simple package management on a single machine or on groups of them.
The following sections assume your system was registered with Red Hat Subscription Management during installation as described in the Red Hat Enterprise Linux 7 Installation Guide. If your system is not subscribed, see Chapter 6, Registering the System and Managing Subscriptions.

Important

Yum provides secure package management by enabling GPG (Gnu Privacy Guard; also known as GnuPG) signature verification on GPG-signed packages to be turned on for all package repositories (package sources), or for individual repositories. When signature verification is enabled, yum will refuse to install any packages not GPG-signed with the correct key for that repository. This means that you can trust that the RPM packages you download and install on your system are from a trusted source, such as Red Hat, and were not modified during transfer. See Section 8.5, “Configuring Yum and Yum Repositories” for details on enabling signature-checking with yum, or Section A.3.2, “Checking Package Signatures” for information on working with and verifying GPG-signed RPM packages in general.
Yum also enables you to easily set up your own repositories of RPM packages for download and installation on other machines. When possible, yum uses parallel download of multiple packages and metadata to speed up downloading.
Learning yum is a worthwhile investment because it is often the fastest way to perform system administration tasks, and it provides capabilities beyond those provided by the PackageKit graphical package management tools.

Note

You must have superuser privileges in order to use yum to install, update or remove packages on your system. All examples in this chapter assume that you have already obtained superuser privileges by using either the su or sudo command.

8.1. Checking For and Updating Packages

Yum enables you to check if your system has any updates waiting to be applied. You can list packages that need to be updated and update them as a whole, or you can update a selected individual package.

8.1.1. Checking For Updates

To see which installed packages on your system have updates available, use the following command:
yum check-update

Example 8.1. Example output of the yum check-update command

The output of yum check-update can look as follows:
~]# yum check-update
Loaded plugins: product-id, search-disabled-repos, subscription-manager
dracut.x86_64                         033-360.el7_2      rhel-7-server-rpms
dracut-config-rescue.x86_64           033-360.el7_2      rhel-7-server-rpms
kernel.x86_64                         3.10.0-327.el7     rhel-7-server-rpms
rpm.x86_64                            4.11.3-17.el7      rhel-7-server-rpms
rpm-libs.x86_64                       4.11.3-17.el7      rhel-7-server-rpms
rpm-python.x86_64                     4.11.3-17.el7      rhel-7-server-rpms
yum.noarch                            3.4.3-132.el7      rhel-7-server-rpms
The packages in the above output are listed as having updates available. The first package in the list is dracut. Each line in the example output consists of several rows, in case of dracut:
  • dracut — the name of the package,
  • x86_64 — the CPU architecture the package was built for,
  • 033 — the version of the updated package to be installed,
  • 360.el7 — the release of the updated package,
  • _2 — a build version, added as part of a z-stream update,
  • rhel-7-server-rpms — the repository in which the updated package is located.
The output also shows that we can update the kernel (the kernel package), yum and RPM themselves (the yum and rpm packages), as well as their dependencies (such as the rpm-libs, and rpm-python packages), all using the yum command.

8.1.2. Updating Packages

You can choose to update a single package, multiple packages, or all packages at once. If any dependencies of the package or packages you update have updates available themselves, then they are updated too.

Updating a Single Package

To update a single package, run the following command as root:
yum update package_name

Example 8.2. Updating the rpm package

To update the rpm package, type:
~]# yum update rpm
Loaded plugins: langpacks, product-id, subscription-manager
Updating Red Hat repositories.
INFO:rhsm-app.repolib:repos updated: 0
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package rpm.x86_64 0:4.11.1-3.el7 will be updated
--> Processing Dependency: rpm = 4.11.1-3.el7 for package: rpm-libs-4.11.1-3.el7.x86_64
--> Processing Dependency: rpm = 4.11.1-3.el7 for package: rpm-python-4.11.1-3.el7.x86_64
--> Processing Dependency: rpm = 4.11.1-3.el7 for package: rpm-build-4.11.1-3.el7.x86_64
---> Package rpm.x86_64 0:4.11.2-2.el7 will be an update
--> Running transaction check
...
--> Finished Dependency Resolution

Dependencies Resolved
=============================================================================
 Package                   Arch        Version         Repository       Size
=============================================================================
Updating:
 rpm                       x86_64      4.11.2-2.el7    rhel            1.1 M
Updating for dependencies:
 rpm-build                 x86_64      4.11.2-2.el7    rhel            139 k
 rpm-build-libs            x86_64      4.11.2-2.el7    rhel             98 k
 rpm-libs                  x86_64      4.11.2-2.el7    rhel            261 k
 rpm-python                x86_64      4.11.2-2.el7    rhel             74 k

Transaction Summary
=============================================================================
Upgrade  1 Package (+4 Dependent packages)

Total size: 1.7 M
Is this ok [y/d/N]:
This output contains several items of interest:
  1. Loaded plugins: langpacks, product-id, subscription-manager — Yum always informs you which yum plug-ins are installed and enabled. See Section 8.6, “Yum Plug-ins” for general information on yum plug-ins, or Section 8.6.3, “Working with Yum Plug-ins” for descriptions of specific plug-ins.
  2. rpm.x86_64 — you can download and install a new rpm package as well as its dependencies. Transaction check is performed for each of these packages.
  3. Yum presents the update information and then prompts you for confirmation of the update; yum runs interactively by default. If you already know which transactions the yum command plans to perform, you can use the -y option to automatically answer yes to any questions that yum asks (in which case it runs non-interactively). However, you should always examine which changes yum plans to make to the system so that you can easily troubleshoot any problems that might arise. You can also choose to download the package without installing it. To do so, select the d option at the download prompt. This launches a background download of the selected package.
    If a transaction fails, you can view yum transaction history by using the yum history command as described in Section 8.4, “Working with Transaction History”.

Important

Yum always installs a new kernel regardless of whether you are using the yum update or yum install command.
When using RPM, on the other hand, it is important to use the rpm -i kernel command which installs a new kernel instead of rpm -u kernel which replaces the current kernel. See Section A.2.1, “Installing and Upgrading Packages” for more information on installing and upgrading kernels with RPM.
Similarly, it is possible to update a package group. Type as root:
yum group update group_name
Here, replace group_name with a name of the package group you want to update. For more information on package groups, see Section 8.3, “Working with Package Groups”.
Yum also offers the upgrade command that is equal to update with enabled obsoletes configuration option (see Section 8.5.1, “Setting [main] Options”). By default, obsoletes is turned on in /etc/yum.conf, which makes these two commands equivalent.

Updating All Packages and Their Dependencies

To update all packages and their dependencies, use the yum update command without any arguments:
yum update
If packages have security updates available, you can update only these packages to their latest versions. Type as root:
yum update --security
You can also update packages only to versions containing the latest security updates. Type as root:
yum update-minimal --security
For example, assume that:
  • the kernel-3.10.0-1 package is installed on your system;
  • the kernel-3.10.0-2 package was released as a security update;
  • the kernel-3.10.0-3 package was released as a bug fix update.
Then yum update-minimal --security updates the package to kernel-3.10.0-2, and yum update --security updates the package to kernel-3.10.0-3.

8.1.3. Preserving Configuration File Changes

You will inevitably make changes to the configuration files installed by packages as you use your Red Hat Enterprise Linux system. RPM, which yum uses to perform changes to the system, provides a mechanism for ensuring their integrity. See Section A.2.1, “Installing and Upgrading Packages” for details on how to manage changes to configuration files across package upgrades.

8.1.4. Upgrading the System Off-line with ISO and Yum

For systems that are disconnected from the Internet or Red Hat Network, using the yum update command with the Red Hat Enterprise Linux installation ISO image is an easy and quick way to upgrade systems to the latest minor version. The following steps illustrate the upgrading process:
  1. Create a target directory to mount your ISO image. This directory is not automatically created when mounting, so create it before proceeding to the next step. As root, type:
    mkdir mount_dir
    Replace mount_dir with a path to the mount directory. Typically, users create it as a subdirectory in the /media directory.
  2. Mount the Red Hat Enterprise Linux 7 installation ISO image to the previously created target directory. As root, type:
    mount -o loop iso_name mount_dir
    Replace iso_name with a path to your ISO image and mount_dir with a path to the target directory. Here, the -o loop option is required to mount the file as a block device.
  3. Copy the media.repo file from the mount directory to the /etc/yum.repos.d/ directory. Note that configuration files in this directory must have the .repo extension to function properly.
    cp mount_dir/media.repo /etc/yum.repos.d/new.repo
    This creates a configuration file for the yum repository. Replace new.repo with the filename, for example rhel7.repo.
  4. Edit the new configuration file so that it points to the Red Hat Enterprise Linux installation ISO. Add the following line into the /etc/yum.repos.d/new.repo file:
    baseurl=file:///mount_dir
    Replace mount_dir with a path to the mount point.
  5. Update all yum repositories including /etc/yum.repos.d/new.repo created in previous steps. As root, type:
    yum update
    This upgrades your system to the version provided by the mounted ISO image.
  6. After successful upgrade, you can unmount the ISO image. As root, type:
    umount mount_dir
    where mount_dir is a path to your mount directory. Also, you can remove the mount directory created in the first step. As root, type:
    rmdir mount_dir
  7. If you will not use the previously created configuration file for another installation or update, you can remove it. As root, type:
    rm /etc/yum.repos.d/new.repo

Example 8.3. Upgrading from Red Hat Enterprise Linux 7.0 to 7.1

If required to upgrade a system without access to the Internet using an ISO image with the newer version of the system, called for example rhel-server-7.1-x86_64-dvd.iso, create a target directory for mounting, such as /media/rhel7/. As root, change into the directory with your ISO image and type:
~]# mount -o loop rhel-server-7.1-x86_64-dvd.iso /media/rhel7/
Then set up a yum repository for your image by copying the media.repo file from the mount directory:
~]# cp /media/rhel7/media.repo /etc/yum.repos.d/rhel7.repo
To make yum recognize the mount point as a repository, add the following line into the /etc/yum.repos.d/rhel7.repo copied in the previous step:
baseurl=file:///media/rhel7/
Now, updating the yum repository will upgrade your system to a version provided by rhel-server-7.1-x86_64-dvd.iso. As root, execute:
~]# yum update
When your system is successfully upgraded, you can unmount the image, remove the target directory and the configuration file:
~]# umount /media/rhel7/
~]# rmdir /media/rhel7/
~]# rm /etc/yum.repos.d/rhel7.repo

8.2. Working with Packages

Yum enables you to perform a complete set of operations with software packages, including searching for packages, viewing information about them, installing and removing.

8.2.1. Searching Packages

You can search all RPM package names, descriptions and summaries by using the following command:
yum search term
Replace term with a package name you want to search.

Example 8.4. Searching for packages matching a specific string

To list all packages that match vim, gvim, or emacs, type:
~]$ yum search vim gvim emacs
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
============================= N/S matched: vim ==============================
vim-X11.x86_64 : The VIM version of the vi editor for the X Window System
vim-common.x86_64 : The common files needed by any version of the VIM editor
[output truncated]

============================ N/S matched: emacs =============================
emacs.x86_64 : GNU Emacs text editor
emacs-auctex.noarch : Enhanced TeX modes for Emacs
[output truncated]

  Name and summary matches mostly, use "search all" for everything.
Warning: No matches found for: gvim
The yum search command is useful for searching for packages you do not know the name of, but for which you know a related term. Note that by default, yum search returns matches in package name and summary, which makes the search faster. Use the yum search all command for a more exhaustive but slower search.

Filtering the Results

All of yum's list commands allow you to filter the results by appending one or more glob expressions as arguments. Glob expressions are normal strings of characters which contain one or more of the wildcard characters * (which expands to match any character subset) and ? (which expands to match any single character).
Be careful to escape the glob expressions when passing them as arguments to a yum command, otherwise the Bash shell will interpret these expressions as pathname expansions, and potentially pass all files in the current directory that match the global expressions to yum. To make sure the glob expressions are passed to yum as intended, use one of the following methods:
  • escape the wildcard characters by preceding them with a backslash character
  • double-quote or single-quote the entire glob expression.
Examples in the following section demonstrate usage of both these methods.

8.2.2. Listing Packages

To list information on all installed and available packages type the following at a shell prompt:
yum list all
To list installed and available packages that match inserted glob expressions use the following command:
yum list glob_expression

Example 8.5. Listing ABRT-related packages

Packages with various ABRT add-ons and plug-ins either begin with abrt-addon-, or abrt-plugin-. To list these packages, type the following command at a shell prompt. Note how the wildcard characters are escaped with a backslash character:
~]$ yum list abrt-addon\* abrt-plugin\*
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Installed Packages
abrt-addon-ccpp.x86_64                   2.1.11-35.el7             @rhel-7-server-rpms
abrt-addon-kerneloops.x86_64             2.1.11-35.el7             @rhel-7-server-rpms
abrt-addon-pstoreoops.x86_64             2.1.11-35.el7             @rhel-7-server-rpms
abrt-addon-python.x86_64                 2.1.11-35.el7             @rhel-7-server-rpms
abrt-addon-vmcore.x86_64                 2.1.11-35.el7             @rhel-7-server-rpms
abrt-addon-xorg.x86_64                   2.1.11-35.el7             @rhel-7-server-rpms
To list all packages installed on your system use the installed keyword. The rightmost column in the output lists the repository from which the package was retrieved.
yum list installed glob_expression

Example 8.6. Listing all installed versions of the krb package

The following example shows how to list all installed packages that begin with krb followed by exactly one character and a hyphen. This is useful when you want to list all versions of certain component as these are distinguished by numbers. The entire glob expression is quoted to ensure proper processing.
~]$ yum list installed "krb?-*"
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Installed Packages
krb5-libs.x86_64                  1.13.2-10.el7                   @rhel-7-server-rpms
To list all packages in all enabled repositories that are available to install, use the command in the following form:
yum list available glob_expression

Example 8.7. Listing available gstreamer plug-ins

For instance, to list all available packages with names that contain gstreamer and then plugin, run the following command:
~]$ yum list available gstreamer\*plugin\*
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Available Packages
gstreamer-plugins-bad-free.i686             0.10.23-20.el7         rhel-7-server-rpms
gstreamer-plugins-base.i686                 0.10.36-10.el7         rhel-7-server-rpms
gstreamer-plugins-good.i686                 0.10.31-11.el7         rhel-7-server-rpms
gstreamer1-plugins-bad-free.i686            1.4.5-3.el7            rhel-7-server-rpms
gstreamer1-plugins-base.i686                1.4.5-2.el7            rhel-7-server-rpms
gstreamer1-plugins-base-devel.i686          1.4.5-2.el7            rhel-7-server-rpms
gstreamer1-plugins-base-devel.x86_64        1.4.5-2.el7            rhel-7-server-rpms
gstreamer1-plugins-good.i686                1.4.5-2.el7            rhel-7-server-rpms

Listing Repositories

To list the repository ID, name, and number of packages for each enabled repository on your system, use the following command:
yum repolist
To list more information about these repositories, add the -v option. With this option enabled, information including the file name, overall size, date of the last update, and base URL are displayed for each listed repository. As an alternative, you can use the repoinfo command that produces the same output.
yum repolist -v
yum repoinfo 
To list both enabled and disabled repositories use the following command. A status column is added to the output list to show which of the repositories are enabled.
yum repolist all
By passing disabled as a first argument, you can reduce the command output to disabled repositories. For further specification you can pass the ID or name of repositories or related glob_expressions as arguments. Note that if there is an exact match between the repository ID or name and the inserted argument, this repository is listed even if it does not pass the enabled or disabled filter.

8.2.3. Displaying Package Information

To display information about one or more packages, use the following command (glob expressions are valid here as well):
yum info package_name
Replace package_name with the name of the package.

Example 8.8. Displaying information on the abrt package

To display information about the abrt package, type:
~]$ yum info abrt
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Installed Packages
Name        : abrt
Arch        : x86_64
Version     : 2.1.11
Release     : 35.el7
Size        : 2.3 M
Repo        : installed
From repo   : rhel-7-server-rpms
Summary     : Automatic bug detection and reporting tool
URL         : https://fedorahosted.org/abrt/
License     : GPLv2+
Description : abrt is a tool to help users to detect defects in applications and
            : to create a bug report with all information needed by maintainer to fix
            : it. It uses plugin system to extend its functionality.
The yum info package_name command is similar to the rpm -q --info package_name command, but provides as additional information the name of the yum repository the RPM package was installed from (look for the From repo: line in the output).

Using yumdb

You can also query the yum database for alternative and useful information about a package by using the following command:
yumdb info package_name
This command provides additional information about a package, including the check sum of the package (and the algorithm used to produce it, such as SHA-256), the command given on the command line that was invoked to install the package (if any), and the reason why the package is installed on the system (where user indicates it was installed by the user, and dep means it was brought in as a dependency).

Example 8.9. Querying yumdb for information on the yum package

To display additional information about the yum package, type:
~]$ yumdb info yum
Loaded plugins: langpacks, product-id
yum-3.4.3-132.el7.noarch
     changed_by = 1000
     checksum_data = a9d0510e2ff0d04d04476c693c0313a11379053928efd29561f9a837b3d9eb02
     checksum_type = sha256
     command_line = upgrade
     from_repo = rhel-7-server-rpms
     from_repo_revision = 1449144806
     from_repo_timestamp = 1449144805
     installed_by = 4294967295
     origin_url = https://cdn.redhat.com/content/dist/rhel/server/7/7Server/x86_64/os/Packages/yum-3.4.3-132.el7.noarch.rpm
     reason = user
     releasever = 7Server
     var_uuid = 147a7d49-b60a-429f-8d8f-3edb6ce6f4a1
For more information on the yumdb command, see the yumdb(8) manual page.

8.2.4. Installing Packages

To install a single package and all of its non-installed dependencies, enter a command in the following form as root:
yum install package_name
You can also install multiple packages simultaneously by appending their names as arguments. To do so, type as root:
yum install package_name package_name
If you are installing packages on a multilib system, such as an AMD64 or Intel 64 machine, you can specify the architecture of the package (as long as it is available in an enabled repository) by appending .arch to the package name:
yum install package_name.arch

Example 8.10. Installing packages on multilib system

To install the sqlite package for the i686 architecture, type:
~]# yum install sqlite.i686
You can use glob expressions to quickly install multiple similarly named packages. Execute as root:
yum install glob_expression

Example 8.11. Installing all audacious plugins

Global expressions are useful when you want to install several packages with similar names. To install all audacious plug-ins, use the command in the following form:
~]# yum install audacious-plugins-\*
In addition to package names and glob expressions, you can also provide file names to yum install. If you know the name of the binary you want to install, but not its package name, you can give yum install the path name. As root, type:
yum install /usr/sbin/named
Yum then searches through its package lists, finds the package which provides /usr/sbin/named, if any, and prompts you as to whether you want to install it.
As you can see in the above examples, the yum install command does not require strictly defined arguments. It can process various formats of package names and glob expressions, which makes installation easier for users. On the other hand, it takes some time until yum parses the input correctly, especially if you specify a large number of packages. To optimize the package search, you can use the following commands to explicitly define how to parse the arguments:
yum install-n name
yum install-na name.architecture
yum install-nevra name-epoch:version-release.architecture
With install-n, yum interprets name as the exact name of the package. The install-na command tells yum that the subsequent argument contains the package name and architecture divided by the dot character. With install-nevra, yum will expect an argument in the form name-epoch:version-release.architecture. Similarly, you can use yum remove-n, yum remove-na, and yum remove-nevra when searching for packages to be removed.

Note

If you know you want to install the package that contains the named binary, but you do not know in which bin/ or sbin/ directory the file is installed, use the yum provides command with a glob expression:
~]# yum provides "*bin/named"
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-
              : manager
32:bind-9.9.4-14.el7.x86_64 : The Berkeley Internet Name Domain (BIND) DNS
                            : (Domain Name System) server
Repo        : rhel-7-server-rpms
Matched from:
Filename    : /usr/sbin/named
yum provides "*/file_name" is a useful way to find the packages that contain file_name.

Example 8.12. Installation Process

The following example provides an overview of installation with use of yum. To download and install the latest version of the httpd package, execute as root:
~]# yum install httpd
Loaded plugins: langpacks, product-id, subscription-manager
Resolving Dependencies
--> Running transaction check
---> Package httpd.x86_64 0:2.4.6-12.el7 will be updated
---> Package httpd.x86_64 0:2.4.6-13.el7 will be an update
--> Processing Dependency: 2.4.6-13.el7 for package: httpd-2.4.6-13.el7.x86_64
--> Running transaction check
---> Package httpd-tools.x86_64 0:2.4.6-12.el7 will be updated
---> Package httpd-tools.x86_64 0:2.4.6-13.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved
After executing the above command, yum loads the necessary plug-ins and runs the transaction check. In this case, httpd is already installed. Since the installed package is older than the latest currently available version, it will be updated. The same applies to the httpd-tools package that httpd depends on. Then, a transaction summary is displayed:

================================================================================
 Package        Arch      Version                 Repository               Size
================================================================================
Updating:
 httpd          x86_64    2.4.6-13.el7            rhel-x86_64-server-7    1.2 M
Updating for dependencies:
 httpd-tools    x86_64    2.4.6-13.el7            rhel-x86_64-server-7     77 k

Transaction Summary
================================================================================
Upgrade  1 Package (+1 Dependent package)

Total size: 1.2 M
Is this ok [y/d/N]:
In this step yum prompts you to confirm the installation. Apart from y (yes) and N (no) options, you can choose d (download only) to download the packages but not to install them directly. If you choose y, the installation proceeds with the following messages until it is finished successfully.
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Updating   : httpd-tools-2.4.6-13.el7.x86_64                             1/4 
  Updating   : httpd-2.4.6-13.el7.x86_64                                   2/4 
  Cleanup    : httpd-2.4.6-12.el7.x86_64                                   3/4 
  Cleanup    : httpd-tools-2.4.6-12.el7.x86_64                             4/4 
  Verifying  : httpd-2.4.6-13.el7.x86_64                                   1/4 
  Verifying  : httpd-tools-2.4.6-13.el7.x86_64                             2/4 
  Verifying  : httpd-tools-2.4.6-12.el7.x86_64                             3/4 
  Verifying  : httpd-2.4.6-12.el7.x86_64                                   4/4 

Updated:
  httpd.x86_64 0:2.4.6-13.el7

Dependency Updated:
  httpd-tools.x86_64 0:2.4.6-13.el7

Complete!
To install a previously downloaded package from the local directory on your system, use the following command:
yum localinstall path
Replace path with the path to the package you want to install.

8.2.5. Downloading Packages

As shown in Example 8.12, “Installation Process”, at a certain point of installation process you are prompted to confirm the installation with the following message:
...
Total size: 1.2 M
Is this ok [y/d/N]:    
...
With the d option, yum downloads the packages without installing them immediately. You can install these packages later offline with the yum localinstall command or you can share them with a different device. Downloaded packages are saved in one of the subdirectories of the cache directory, by default /var/cache/yum/$basearch/$releasever/packages/. The downloading proceeds in background mode so that you can use yum for other operations in parallel.

8.2.6. Removing Packages

Similarly to package installation, yum enables you to uninstall them. To uninstall a particular package, as well as any packages that depend on it, run the following command as root:
yum remove package_name
As when you install multiple packages, you can remove several at once by adding more package names to the command.

Example 8.13. Removing several packages

To remove totem, type the following at a shell prompt:
~]# yum remove totem
Similar to install, remove can take these arguments:
  • package names
  • glob expressions
  • file lists
  • package provides

Warning

Yum is not able to remove a package without also removing packages which depend on it. This type of operation, which can only be performed by RPM, is not advised, and can potentially leave your system in a non-functioning state or cause applications to not work correctly or crash. For further information, see Section A.2.2, “Uninstalling Packages” in the RPM chapter.

8.3. Working with Package Groups

A package group is a collection of packages that serve a common purpose, for instance System Tools or Sound and Video. Installing a package group pulls a set of dependent packages, saving time considerably. The yum groups command is a top-level command that covers all the operations that act on package groups in yum.

8.3.1. Listing Package Groups

The summary option is used to view the number of installed groups, available groups, available environment groups, and both installed and available language groups:
yum groups summary

Example 8.14. Example output of yum groups summary

~]$ yum groups summary 
Loaded plugins: langpacks, product-id, subscription-manager
Available Environment Groups: 12
Installed Groups: 10
Available Groups: 12
To list all package groups from yum repositories add the list option. You can filter the command output by group names.
yum group list glob_expression
Several optional arguments can be passed to this command, including hidden to list also groups not marked as user visible, and ids to list group IDs. You can add language, environment, installed, or available options to reduce the command output to a specific group type.
To list mandatory and optional packages contained in a particular group, use the following command:
yum group info glob_expression

Example 8.15. Viewing information on the LibreOffice package group

 ~]$ yum group info LibreOffice
Loaded plugins: langpacks, product-id, subscription-manager

Group: LibreOffice
 Group-Id: libreoffice
 Description: LibreOffice Productivity Suite
 Mandatory Packages:
  =libreoffice-calc
   libreoffice-draw
  -libreoffice-emailmerge
   libreoffice-graphicfilter
  =libreoffice-impress
  =libreoffice-math
  =libreoffice-writer
  +libreoffice-xsltfilter
 Optional Packages:
   libreoffice-base
   libreoffice-pyuno
As you can see in the above example, the packages included in the package group can have different states that are marked with the following symbols:
  • " - " — Package is not installed and it will not be installed as a part of the package group.
  • " + " — Package is not installed but it will be installed on the next yum upgrade or yum group upgrade.
  • " = " — Package is installed and it was installed as a part of the package group.
  • no symbol — Package is installed but it was installed outside of the package group. This means that the yum group remove will not remove these packages.
These distinctions take place only when the group_command configuration parameter is set to objects, which is the default setting. Set this parameter to a different value if you do not want yum to track if a package was installed as a part of the group or separately, which will make "no symbol" packages equivalent to "=" packages.
You can alter the above package states using the yum group mark command. For example, yum group mark packages marks any given installed packages as members of a specified group. To avoid installation of new packages on group update, use yum group mark blacklist. See the yum(8) man page for more information on capabilities of yum group mark.

Note

You can identify an environmental group with use of the @^ prefix and a package group can be marked with @. When using yum group list, info, install, or remove, pass @group_name to specify a package group, @^group_name to specify an environmental group, or group_name to include both.

8.3.2. Installing a Package Group

Each package group has a name and a group ID (groupid). To list the names of all package groups, and their group IDs, which are displayed in parentheses, type:
yum group list ids 

Example 8.16. Finding name and groupid of a package group

To find the name or ID of a package group, for example a group related to the KDE desktop environment, type:
~]$ yum group list ids kde\*
Available environment groups:
   KDE Plasma Workspaces (kde-desktop-environment)
Done
Some groups are hidden by settings in the configured repositories. For example, on a server, make use of the hidden command option to list hidden groups too:
~]$ yum group list hidden ids kde\*
Loaded plugins: product-id, subscription-manager
Available Groups:
   KDE (kde-desktop)
Done
You can install a package group by passing its full group name, without the groupid part, to the group install command. As root, type:
yum group install "group name"
You can also install by groupid. As root, execute the following command:
yum group install groupid
You can pass the groupid or quoted group name to the install command if you prepend it with an @ symbol, which tells yum that you want to perform group install. As root, type:
yum install @group
Replace group with the groupid or quoted group name. The same logic applies to environmental groups:
yum install @^group

Example 8.17. Four equivalent ways of installing the KDE Desktop group

As mentioned before, you can use four alternative, but equivalent ways to install a package group. For KDE Desktop, the commands look as follows:
~]# yum group install "KDE Desktop"
~]# yum group install kde-desktop
~]# yum install @"KDE Desktop"
~]# yum install @kde-desktop

8.3.3. Removing a Package Group

You can remove a package group using syntax similar to the install syntax, with use of either name of the package group or its id. As root, type:
yum group remove group_name
yum group remove groupid
Also, you can pass the groupid or quoted name to the remove command if you prepend it with an @-symbol, which tells yum that you want to perform group remove. As root, type:
yum remove @group
Replace group with the groupid or quoted group name. Similarly, you can replace an environmental group:
yum remove @^group

Example 8.18. Four equivalent ways of removing the KDE Desktop group

Similarly to install, you can use four alternative, but equivalent ways to remove a package group. For KDE Desktop, the commands look as follows:
~]# yum group remove "KDE Desktop"
~]# yum group remove kde-desktop
~]# yum remove @"KDE Desktop"
~]# yum remove @kde-desktop

8.4. Working with Transaction History

The yum history command enables users to review information about a timeline of yum transactions, the dates and times they occurred, the number of packages affected, whether these transactions succeeded or were aborted, and if the RPM database was changed between transactions. Additionally, this command can be used to undo or redo certain transactions. All history data is stored in the history DB in the /var/lib/yum/history/ directory.

8.4.1. Listing Transactions

To display a list of the twenty most recent transactions, as root, either run yum history with no additional arguments, or type the following at a shell prompt:
yum history list
To display all transactions, add the all keyword:
yum history list all
To display only transactions in a given range, use the command in the following form:
yum history list start_id..end_id
You can also list only transactions regarding a particular package or packages. To do so, use the command with a package name or a glob expression:
yum history list glob_expression

Example 8.19. Listing the five oldest transactions

In the output of yum history list, the most recent transaction is displayed at the top of the list. To display information about the five oldest transactions stored in the history data base, type:
~]# yum history list 1..5
Loaded plugins: langpacks, product-id, subscription-manager
ID     | Login user               | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
     5 | User <user>              | 2013-07-29 15:33 | Install        |    1
     4 | User <user>              | 2013-07-21 15:10 | Install        |    1
     3 | User <user>              | 2013-07-16 15:27 | I, U           |   73
     2 | System <unset>           | 2013-07-16 15:19 | Update         |    1
     1 | System <unset>           | 2013-07-16 14:38 | Install        | 1106
history list
All forms of the yum history list command produce tabular output with each row consisting of the following columns:
  • ID — an integer value that identifies a particular transaction.
  • Login user — the name of the user whose login session was used to initiate a transaction. This information is typically presented in the Full Name <username> form. For transactions that were not issued by a user (such as an automatic system update), System <unset> is used instead.
  • Date and time — the date and time when a transaction was issued.
  • Action(s) — a list of actions that were performed during a transaction as described in Table 8.1, “Possible values of the Action(s) field”.
  • Altered — the number of packages that were affected by a transaction, possibly followed by additional information as described in Table 8.2, “Possible values of the Altered field”.

Table 8.1. Possible values of the Action(s) field

Action Abbreviation Description
Downgrade D At least one package has been downgraded to an older version.
Erase E At least one package has been removed.
Install I At least one new package has been installed.
Obsoleting O At least one package has been marked as obsolete.
Reinstall R At least one package has been reinstalled.
Update U At least one package has been updated to a newer version.

Table 8.2. Possible values of the Altered field

Symbol Description
< Before the transaction finished, the rpmdb database was changed outside yum.
> After the transaction finished, the rpmdb database was changed outside yum.
* The transaction failed to finish.
# The transaction finished successfully, but yum returned a non-zero exit code.
E The transaction finished successfully, but an error or a warning was displayed.
P The transaction finished successfully, but problems already existed in the rpmdb database.
s The transaction finished successfully, but the --skip-broken command-line option was used and certain packages were skipped.
To synchronize the rpmdb or yumdb database contents for any installed package with the currently used rpmdb or yumdb database, type the following:
yum history sync
To display some overall statistics about the currently used history database use the following command:
yum history stats

Example 8.20. Example output of yum history stats

~]# yum history stats
Loaded plugins: langpacks, product-id, subscription-manager 
File        : //var/lib/yum/history/history-2012-08-15.sqlite
Size        : 2,766,848
Transactions: 41
Begin time  : Wed Aug 15 16:18:25 2012
End time    : Wed Feb 27 14:52:30 2013
Counts      :
  NEVRAC :  2,204
  NEVRA  :  2,204
  NA     :  1,759
  NEVR   :  2,204
  rpm DB :  2,204
  yum DB :  2,204
history stats
Yum also enables you to display a summary of all past transactions. To do so, run the command in the following form as root:
yum history summary
To display only transactions in a given range, type:
yum history summary start_id..end_id
Similarly to the yum history list command, you can also display a summary of transactions regarding a certain package or packages by supplying a package name or a glob expression:
yum history summary glob_expression

Example 8.21. Summary of the five latest transactions

~]# yum history summary 1..5
Loaded plugins: langpacks, product-id, subscription-manager
Login user                 | Time                | Action(s)        | Altered 
-------------------------------------------------------------------------------
Jaromir ... <jhradilek>    | Last day            | Install          |        1
Jaromir ... <jhradilek>    | Last week           | Install          |        1
Jaromir ... <jhradilek>    | Last 2 weeks        | I, U             |       73
System <unset>             | Last 2 weeks        | I, U             |     1107
history summary
All forms of the yum history summary command produce simplified tabular output similar to the output of yum history list.
As shown above, both yum history list and yum history summary are oriented towards transactions, and although they allow you to display only transactions related to a given package or packages, they lack important details, such as package versions. To list transactions from the perspective of a package, run the following command as root:
yum history package-list glob_expression

Example 8.22. Tracing the history of a package

For example, to trace the history of subscription-manager and related packages, type the following at a shell prompt:
~]# yum history package-list subscription-manager\*
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
ID     | Action(s)      | Package
-------------------------------------------------------------------------------
     2 | Updated        | subscription-manager-1.13.22-1.el7.x86_64          EE
     2 | Update         |                      1.15.9-15.el7.x86_64          EE
     2 | Obsoleted      | subscription-manager-firstboot-1.13.22-1.el7.x86_64 EE
     2 | Updated        | subscription-manager-gui-1.13.22-1.el7.x86_64      EE
     2 | Update         |                          1.15.9-15.el7.x86_64      EE
     2 | Obsoleting     | subscription-manager-initial-setup-addon-1.15.9-15.el7.x86_64 EE
     1 | Install        | subscription-manager-1.13.22-1.el7.x86_64
     1 | Install        | subscription-manager-firstboot-1.13.22-1.el7.x86_64
     1 | Install        | subscription-manager-gui-1.13.22-1.el7.x86_64
history package-list
In this example, three packages were installed during the initial system installation: subscription-manager, subscription-manager-firstboot, and subscription-manager-gui. In the third transaction, all these packages were updated from version 1.10.11 to version 1.10.17.

8.4.2. Examining Transactions

To display the summary of a single transaction, as root, use the yum history summary command in the following form:
yum history summary id
Here, id stands for the ID of the transaction.
To examine a particular transaction or transactions in more detail, run the following command as root:
yum history info id
The id argument is optional and when you omit it, yum automatically uses the last transaction. Note that when specifying more than one transaction, you can also use a range:
yum history info start_id..end_id

Example 8.23. Example output of yum history info

The following is sample output for two transactions, each installing one new package:
~]# yum history info 4..5
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Transaction ID : 4..5
Begin time     : Mon Dec  7 16:51:07 2015
Begin rpmdb    : 1252:d2b62b7b5768e855723954852fd7e55f641fbad9
End time       :            17:18:49 2015 (27 minutes)
End rpmdb      : 1253:cf8449dc4c53fc0cbc0a4c48e496a6c50f3d43c5
User           : Maxim Svistunov <msvistun>
Return-Code    : Success
Command Line   : install tigervnc-server.x86_64
Command Line   : reinstall tigervnc-server
Transaction performed with:
    Installed     rpm-4.11.3-17.el7.x86_64                  @rhel-7-server-rpms
    Installed     subscription-manager-1.15.9-15.el7.x86_64 @rhel-7-server-rpms
    Installed     yum-3.4.3-132.el7.noarch                  @rhel-7-server-rpms
Packages Altered:
    Reinstall tigervnc-server-1.3.1-3.el7.x86_64 @rhel-7-server-rpms
history info
You can also view additional information, such as what configuration options were used at the time of the transaction, or from what repository and why were certain packages installed. To determine what additional information is available for a certain transaction, type the following at a shell prompt as root:
yum history addon-info id
Similarly to yum history info, when no id is provided, yum automatically uses the latest transaction. Another way to refer to the latest transaction is to use the last keyword:
yum history addon-info last

Example 8.24. Example output of yum history addon-info

For the fourth transaction in the history, the yum history addon-info command provides the following output:
~]# yum history addon-info 4
Loaded plugins: langpacks, product-id, subscription-manager
Transaction ID: 4
Available additional history information:
  config-main
  config-repos
  saved_tx

history addon-info
In the output of the yum history addon-info command, three types of information are available:
  • config-main — global yum options that were in use during the transaction. See Section 8.5.1, “Setting [main] Options” for information on how to change global options.
  • config-repos — options for individual yum repositories. See Section 8.5.2, “Setting [repository] Options” for information on how to change options for individual repositories.
  • saved_tx — the data that can be used by the yum load-transaction command in order to repeat the transaction on another machine (see below).
To display a selected type of additional information, run the following command as root:
yum history addon-info id information

8.4.3. Reverting and Repeating Transactions

Apart from reviewing the transaction history, the yum history command provides means to revert or repeat a selected transaction. To revert a transaction, type the following at a shell prompt as root:
yum history undo id
To repeat a particular transaction, as root, run the following command:
yum history redo id
Both commands also accept the last keyword to undo or repeat the latest transaction.
Note that both yum history undo and yum history redo commands only revert or repeat the steps that were performed during a transaction. If the transaction installed a new package, the yum history undo command will uninstall it, and if the transaction uninstalled a package the command will again install it. This command also attempts to downgrade all updated packages to their previous version, if these older packages are still available.
When managing several identical systems, yum also enables you to perform a transaction on one of them, store the transaction details in a file, and after a period of testing, repeat the same transaction on the remaining systems as well. To store the transaction details to a file, type the following at a shell prompt as root:
yum -q history addon-info id saved_tx > file_name
Once you copy this file to the target system, you can repeat the transaction by using the following command as root:
yum load-transaction file_name
You can configure load-transaction to ignore missing packages or rpmdb version. For more information on these configuration options see the yum.conf(5) man page.

8.4.4. Starting New Transaction History

Yum stores the transaction history in a single SQLite database file. To start new transaction history, run the following command as root:
yum history new
This will create a new, empty database file in the /var/lib/yum/history/ directory. The old transaction history will be kept, but will not be accessible as long as a newer database file is present in the directory.

8.5. Configuring Yum and Yum Repositories

Note

To expand your expertise, you might also be interested in the Red Hat System Administration III (RH254) and RHCSA Rapid Track (RH199) training courses.
The configuration information for yum and related utilities is located at /etc/yum.conf. This file contains one mandatory [main] section, which enables you to set yum options that have global effect, and can also contain one or more [repository] sections, which allow you to set repository-specific options. However, it is recommended to define individual repositories in new or existing .repo files in the /etc/yum.repos.d/ directory. The values you define in individual [repository] sections of the /etc/yum.conf file override values set in the [main] section.
This section shows you how to:
  • set global yum options by editing the [main] section of the /etc/yum.conf configuration file;
  • set options for individual repositories by editing the [repository] sections in /etc/yum.conf and .repo files in the /etc/yum.repos.d/ directory;
  • use yum variables in /etc/yum.conf and files in the /etc/yum.repos.d/ directory so that dynamic version and architecture values are handled correctly;
  • add, enable, and disable yum repositories on the command line; and
  • set up your own custom yum repository.

8.5.1. Setting [main] Options

The /etc/yum.conf configuration file contains exactly one [main] section, and while some of the key-value pairs in this section affect how yum operates, others affect how yum treats repositories. You can add many additional options under the [main] section heading in /etc/yum.conf.
A sample /etc/yum.conf configuration file can look like this:
[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3

[comments abridged]

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
The following are the most commonly used options in the [main] section:
assumeyes=value
The assumeyes option determines whether or not yum prompts for confirmation of critical actions. Replace value with one of:
0 (default) — yum prompts for confirmation of critical actions it performs.
1 — Do not prompt for confirmation of critical yum actions. If assumeyes=1 is set, yum behaves in the same way as the command-line options -y and --assumeyes.
cachedir=directory
Use this option to set the directory where yum stores its cache and database files. Replace directory with an absolute path to the directory. By default, yum's cache directory is /var/cache/yum/$basearch/$releasever/.
See Section 8.5.3, “Using Yum Variables” for descriptions of the $basearch and $releasever yum variables.
debuglevel=value
This option specifies the detail of debugging output produced by yum. Here, value is an integer between 1 and 10. Setting a higher debuglevel value causes yum to display more detailed debugging output. debuglevel=2 is the default, while debuglevel=0 disables debugging output.
exactarch=value
With this option, you can set yum to consider the exact architecture when updating already installed packages. Replace value with:
0 — Do not take into account the exact architecture when updating packages.
1 (default) — Consider the exact architecture when updating packages. With this setting, yum does not install a package for 32-bit architecture to update a package already installed on the system with 64-bit architecture.
exclude=package_name [more_package_names]
The exclude option enables you to exclude packages by keyword during installation or system update. Listing multiple packages for exclusion can be accomplished by quoting a space-delimited list of packages. Shell glob expressions using wildcards (for example, * and ?) are allowed.
gpgcheck=value
Use the gpgcheck option to specify if yum should perform a GPG signature check on packages. Replace value with:
0 — Disable GPG signature-checking on packages in all repositories, including local package installation.
1 (default) — Enable checking of GPG signature on all packages in all repositories, including local package installation. With gpgcheck enabled, all packages' signatures are checked.
If this option is set in the [main] section of the /etc/yum.conf file, it sets the GPG-checking rule for all repositories. However, you can also set gpgcheck=value for individual repositories instead; that is, you can enable GPG-checking on one repository while disabling it on another. Setting gpgcheck=value for an individual repository in its corresponding .repo file overrides the default if it is present in /etc/yum.conf.
For more information on GPG signature-checking, see Section A.3.2, “Checking Package Signatures”.
group_command=value
Use the group_command option to specify how the yum group install, yum group upgrade, and yum group remove commands handle a package group. Replace value with on of:
simple — Install all members of a package group. Upgrade only previously installed packages, but do not install packages that have been added to the group in the meantime.
compat — Similar to simple but yum upgrade also installs packages that were added to the group since the previous upgrade.
objects — (default.) With this option, yum keeps track of the previously installed groups and distinguishes between packages installed as a part of the group and packages installed separately. See Example 8.15, “Viewing information on the LibreOffice package group”
group_package_types=package_type [more_package_types]
Here you can specify which type of packages (optional, default or mandatory) is installed when the yum group install command is called. The default and mandatory package types are chosen by default.
history_record=value
With this option, you can set yum to record transaction history. Replace value with one of:
0 — yum should not record history entries for transactions.
1 (default) — yum should record history entries for transactions. This operation takes certain amount of disk space, and some extra time in the transactions, but it provides a lot of information about past operations, which can be displayed with the yum history command. history_record=1 is the default.
For more information on the yum history command, see Section 8.4, “Working with Transaction History”.

Note

Yum uses history records to detect modifications to the rpmdb data base that have been done outside of yum. In such case, yum displays a warning and automatically searches for possible problems caused by altering rpmdb. With history_record turned off, yum is not able to detect these changes and no automatic checks are performed.
installonlypkgs=space separated list of packages
Here you can provide a space-separated list of packages which yum can install, but will never update. See the yum.conf(5) manual page for the list of packages which are install-only by default.
If you add the installonlypkgs directive to /etc/yum.conf, you should ensure that you list all of the packages that should be install-only, including any of those listed under the installonlypkgs section of yum.conf(5). In particular, kernel packages should always be listed in installonlypkgs (as they are by default), and installonly_limit should always be set to a value greater than 2 so that a backup kernel is always available in case the default one fails to boot.
installonly_limit=value
This option sets how many packages listed in the installonlypkgs directive can be installed at the same time. Replace value with an integer representing the maximum number of versions that can be installed simultaneously for any single package listed in installonlypkgs.
The defaults for the installonlypkgs directive include several different kernel packages, so be aware that changing the value of installonly_limit also affects the maximum number of installed versions of any single kernel package. The default value listed in /etc/yum.conf is installonly_limit=3, and it is not recommended to decrease this value, particularly below 2.
keepcache=value
The keepcache option determines whether yum keeps the cache of headers and packages after successful installation. Here, value is one of:
0 (default) — Do not retain the cache of headers and packages after a successful installation.
1 — Retain the cache after a successful installation.
logfile=file_name
To specify the location for logging output, replace file_name with an absolute path to the file in which yum should write its logging output. By default, yum logs to /var/log/yum.log.
max_connenctions=number
Here value stands for the maximum number of simultaneous connections, default is 5.
multilib_policy=value
The multilib_policy option sets the installation behavior if several architecture versions are available for package install. Here, value stands for:
best — install the best-choice architecture for this system. For example, setting multilib_policy=best on an AMD64 system causes yum to install the 64-bit versions of all packages.
all — always install every possible architecture for every package. For example, with multilib_policy set to all on an AMD64 system, yum would install both the i686 and AMD64 versions of a package, if both were available.
obsoletes=value
The obsoletes option enables the obsoletes process logic during updates.When one package declares in its spec file that it obsoletes another package, the latter package is replaced by the former package when the former package is installed. Obsoletes are declared, for example, when a package is renamed. Replace value with one of:
0 — Disable yum's obsoletes processing logic when performing updates.
1 (default) — Enable yum's obsoletes processing logic when performing updates.
plugins=value
This is a global switch to enable or disable yum plug-ins, value is one of:
0 — Disable all yum plug-ins globally.

Important

Disabling all plug-ins is not advised because certain plug-ins provide important yum services. In particular, product-id and subscription-manager plug-ins provide support for the certificate-based Content Delivery Network (CDN). Disabling plug-ins globally is provided as a convenience option, and is generally only recommended when diagnosing a potential problem with yum.
1 (default) — Enable all yum plug-ins globally. With plugins=1, you can still disable a specific yum plug-in by setting enabled=0 in that plug-in's configuration file.
For more information about various yum plug-ins, see Section 8.6, “Yum Plug-ins”. For further information on controlling plug-ins, see Section 8.6.1, “Enabling, Configuring, and Disabling Yum Plug-ins”.
reposdir=directory
Here, directory is an absolute path to the directory where .repo files are located. All .repo files contain repository information (similar to the [repository] sections of /etc/yum.conf). Yum collects all repository information from .repo files and the [repository] section of the /etc/yum.conf file to create a master list of repositories to use for transactions. If reposdir is not set, yum uses the default directory /etc/yum.repos.d/.
retries=value
This option sets the number of times yum should attempt to retrieve a file before returning an error. value is an integer 0 or greater. Setting value to 0 makes yum retry forever. The default value is 10.
For a complete list of available [main] options, see the [main] OPTIONS section of the yum.conf(5) manual page.

8.5.2. Setting [repository] Options

The [repository] sections, where repository is a unique repository ID such as my_personal_repo (spaces are not permitted), allow you to define individual yum repositories. To avoid conflicts, custom repositories should not use names used by Red Hat repositories.
The following is a bare minimum example of the form a [repository] section takes:
[repository]
name=repository_name
baseurl=repository_url
Every [repository] section must contain the following directives:
name=repository_name
Here, repository_name is a human-readable string describing the repository.
baseurl=repository_url
Replace repository_url with a URL to the directory where the repodata directory of a repository is located:
  • If the repository is available over HTTP, use: http://path/to/repo
  • If the repository is available over FTP, use: ftp://path/to/repo
  • If the repository is local to the machine, use: file:///path/to/local/repo
  • If a specific online repository requires basic HTTP authentication, you can specify your user name and password by prepending it to the URL as username:password@link. For example, if a repository on http://www.example.com/repo/ requires a user name of user and a password of password, then the baseurl link could be specified as http://user:password@www.example.com/repo/.
Usually this URL is an HTTP link, such as:
baseurl=http://path/to/repo/releases/$releasever/server/$basearch/os/
Note that yum always expands the $releasever, $arch, and $basearch variables in URLs. For more information about yum variables, see Section 8.5.3, “Using Yum Variables”.
Other useful [repository] directive are:
enabled=value
This is a simple way to tell yum to use or ignore a particular repository, value is one of:
0 — Do not include this repository as a package source when performing updates and installs. This is an easy way of quickly turning repositories on and off, which is useful when you desire a single package from a repository that you do not want to enable for updates or installs.
1 — Include this repository as a package source.
Turning repositories on and off can also be performed by passing either the --enablerepo=repo_name or --disablerepo=repo_name option to yum, or through the Add/Remove Software window of the PackageKit utility.
async=value
Controls parallel downloading of repository packages. Here, value is one of:
auto (default) — parallel downloading is used if possible, which means that yum automatically disables it for repositories created by plug-ins to avoid failures.
on — parallel downloading is enabled for the repository.
off — parallel downloading is disabled for the repository.
Many more [repository] options exist, part of them have the same form and function as certain [main] options. For a complete list, see the [repository] OPTIONS section of the yum.conf(5) manual page.

Example 8.25. A sample /etc/yum.repos.d/redhat.repo file

The following is a sample /etc/yum.repos.d/redhat.repo file:
#
# Red Hat Repositories
# Managed by (rhsm) subscription-manager
#

[red-hat-enterprise-linux-scalable-file-system-for-rhel-6-entitlement-rpms]
name = Red Hat Enterprise Linux Scalable File System (for RHEL 6 Entitlement) (RPMs)
baseurl = https://cdn.redhat.com/content/dist/rhel/entitlement-6/releases/$releasever/$basearch/scalablefilesystem/os
enabled = 1
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
sslverify = 1
sslcacert = /etc/rhsm/ca/redhat-uep.pem
sslclientkey = /etc/pki/entitlement/key.pem
sslclientcert = /etc/pki/entitlement/11300387955690106.pem

[red-hat-enterprise-linux-scalable-file-system-for-rhel-6-entitlement-source-rpms]
name = Red Hat Enterprise Linux Scalable File System (for RHEL 6 Entitlement) (Source RPMs)
baseurl = https://cdn.redhat.com/content/dist/rhel/entitlement-6/releases/$releasever/$basearch/scalablefilesystem/source/SRPMS
enabled = 0
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
sslverify = 1
sslcacert = /etc/rhsm/ca/redhat-uep.pem
sslclientkey = /etc/pki/entitlement/key.pem
sslclientcert = /etc/pki/entitlement/11300387955690106.pem

[red-hat-enterprise-linux-scalable-file-system-for-rhel-6-entitlement-debug-rpms]
name = Red Hat Enterprise Linux Scalable File System (for RHEL 6 Entitlement) (Debug RPMs)
baseurl = https://cdn.redhat.com/content/dist/rhel/entitlement-6/releases/$releasever/$basearch/scalablefilesystem/debug
enabled = 0
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
sslverify = 1
sslcacert = /etc/rhsm/ca/redhat-uep.pem
sslclientkey = /etc/pki/entitlement/key.pem
sslclientcert = /etc/pki/entitlement/11300387955690106.pem

8.5.3. Using Yum Variables

You can use and reference the following built-in variables in yum commands and in all yum configuration files (that is, /etc/yum.conf and all .repo files in the /etc/yum.repos.d/ directory):
$releasever
You can use this variable to reference the release version of Red Hat Enterprise Linux. Yum obtains the value of $releasever from the distroverpkg=value line in the /etc/yum.conf configuration file. If there is no such line in /etc/yum.conf, then yum infers the correct value by deriving the version number from the redhat-releaseproduct package that provides the redhat-release file.
$arch
You can use this variable to refer to the system's CPU architecture as returned when calling Python's os.uname() function. Valid values for $arch include: i586, i686 and x86_64.
$basearch
You can use $basearch to reference the base architecture of the system. For example, i686 and i586 machines both have a base architecture of i386, and AMD64 and Intel 64 machines have a base architecture of x86_64.
$YUM0-9
These ten variables are each replaced with the value of any shell environment variables with the same name. If one of these variables is referenced (in /etc/yum.conf for example) and a shell environment variable with the same name does not exist, then the configuration file variable is not replaced.
To define a custom variable or to override the value of an existing one, create a file with the same name as the variable (without the $ sign) in the /etc/yum/vars/ directory, and add the desired value on its first line.
For example, repository descriptions often include the operating system name. To define a new variable called $osname, create a new file with Red Hat Enterprise Linux on the first line and save it as /etc/yum/vars/osname:
~]# echo "Red Hat Enterprise Linux 7" > /etc/yum/vars/osname
Instead of Red Hat Enterprise Linux 7, you can now use the following in the .repo files:
name=$osname $releasever

8.5.4. Viewing the Current Configuration

To display the current values of global yum options (that is, the options specified in the [main] section of the /etc/yum.conf file), execute the yum-config-manager command with no command-line options:
yum-config-manager
To list the content of a different configuration section or sections, use the command in the following form:
yum-config-manager section
You can also use a glob expression to display the configuration of all matching sections:
yum-config-manager glob_expression

Example 8.26.  Viewing configuration of the main section

To list all configuration options and their corresponding values for the main section, type the following at a shell prompt:
~]$ yum-config-manager main \*
Loaded plugins: langpacks, product-id, subscription-manager
================================== main ===================================
[main]
alwaysprompt = True
assumeyes = False
bandwith = 0
bugtracker_url = https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%206&component=yum
cache = 0
[output truncated]

8.5.5. Adding, Enabling, and Disabling a Yum Repository

Note

To expand your expertise, you might also be interested in the Red Hat System Administration III (RH254) training course.
Section 8.5.2, “Setting [repository] Options” describes various options you can use to define a yum repository. This section explains how to add, enable, and disable a repository by using the yum-config-manager command.

Important

When the system is registered with Red Hat Subscription Management to the certificate-based Content Delivery Network (CDN), the Red Hat Subscription Manager tools are used to manage repositories in the /etc/yum.repos.d/redhat.repo file.

Adding a Yum Repository

To define a new repository, you can either add a [repository] section to the /etc/yum.conf file, or to a .repo file in the /etc/yum.repos.d/ directory. All files with the .repo file extension in this directory are read by yum, and it is recommended to define your repositories here instead of in /etc/yum.conf.

Warning

Obtaining and installing software packages from unverified or untrusted software sources other than Red Hat's certificate-based Content Delivery Network (CDN) constitutes a potential security risk, and could lead to security, stability, compatibility, and maintainability issues.
Yum repositories commonly provide their own .repo file. To add such a repository to your system and enable it, run the following command as root:
yum-config-manager --add-repo repository_url
…where repository_url is a link to the .repo file.

Example 8.27. Adding example.repo

To add a repository located at http://www.example.com/example.repo, type the following at a shell prompt:
~]# yum-config-manager --add-repo http://www.example.com/example.repo
Loaded plugins: langpacks, product-id, subscription-manager
adding repo from: http://www.example.com/example.repo
grabbing file http://www.example.com/example.repo to /etc/yum.repos.d/example.repo
example.repo                                             |  413 B     00:00
repo saved to /etc/yum.repos.d/example.repo

Enabling a Yum Repository

To enable a particular repository or repositories, type the following at a shell prompt as root:
yum-config-manager --enable repository
…where repository is the unique repository ID (use yum repolist all to list available repository IDs). Alternatively, you can use a glob expression to enable all matching repositories:
yum-config-manager --enable glob_expression

Example 8.28. Enabling repositories defined in custom sections of /etc/yum.conf.

To enable repositories defined in the [example], [example-debuginfo], and [example-source]sections, type:
~]# yum-config-manager --enable example\*
Loaded plugins: langpacks, product-id, subscription-manager
============================== repo: example ==============================
[example]
bandwidth = 0
base_persistdir = /var/lib/yum/repos/x86_64/7Server
baseurl = http://www.example.com/repo/7Server/x86_64/
cache = 0
cachedir = /var/cache/yum/x86_64/7Server/example
[output truncated]

Example 8.29. Enabling all repositories

To enable all repositories defined both in the /etc/yum.conf file and in the /etc/yum.repos.d/ directory, type:
~]# yum-config-manager --enable \*
Loaded plugins: langpacks, product-id, subscription-manager
============================== repo: example ==============================
[example]
bandwidth = 0
base_persistdir = /var/lib/yum/repos/x86_64/7Server
baseurl = http://www.example.com/repo/7Server/x86_64/
cache = 0
cachedir = /var/cache/yum/x86_64/7Server/example
[output truncated]
When successful, the yum-config-manager --enable command displays the current repository configuration.

Disabling a Yum Repository

To disable a yum repository, run the following command as root:
yum-config-manager --disable repository
…where repository is the unique repository ID (use yum repolist all to list available repository IDs). Similarly to yum-config-manager --enable, you can use a glob expression to disable all matching repositories at the same time:
yum-config-manager --disable glob_expression

Example 8.30. Disabling all repositories

To disable all repositories defined both in the /etc/yum.conf file and in the /etc/yum.repos.d/ directory, type:
~]# yum-config-manager --disable \*
Loaded plugins: langpacks, product-id, subscription-manager
============================== repo: example ==============================
[example]
bandwidth = 0
base_persistdir = /var/lib/yum/repos/x86_64/7Server
baseurl = http://www.example.com/repo/7Server/x86_64/
cache = 0
cachedir = /var/cache/yum/x86_64/7Server/example
[output truncated]
When successful, the yum-config-manager --disable command displays the current configuration.

8.5.6. Creating a Yum Repository

To set up a yum repository, follow these steps:
  1. Install the createrepo package. To do so, type the following at a shell prompt as root:
    yum install createrepo
  2. Copy all packages that you want to have in your repository into one directory, such as /mnt/local_repo/.
  3. Change to this directory and run the following command:
    createrepo --database /mnt/local_repo
    This creates the necessary metadata for your yum repository, as well as the sqlite database for speeding up yum operations.

8.5.7. Adding the Optional and Supplementary Repositories

The Optional and Supplementary subscription channels provide additional software packages for Red Hat Enterprise Linux that cover open source licensed software (in the Optional channel) and proprietary licensed software (in the Supplementary channel).
Before subscribing to the Optional and Supplementary channels see the Scope of Coverage Details. If you decide to install packages from these channels, follow the steps documented in the article called How to access Optional and Supplementary channels, and -devel packages using Red Hat Subscription Manager (RHSM)? on the Red Hat Customer Portal.

8.6. Yum Plug-ins

Yum provides plug-ins that extend and enhance its operations. Certain plug-ins are installed by default. Yum always informs you which plug-ins, if any, are loaded and active whenever you call any yum command. For example:
~]# yum info yum
Loaded plugins: langpacks, product-id, subscription-manager
[output truncated]
Note that the plug-in names which follow Loaded plugins are the names you can provide to the --disableplugin=plugin_name option.

8.6.1. Enabling, Configuring, and Disabling Yum Plug-ins

To enable yum plug-ins, ensure that a line beginning with plugins= is present in the [main] section of /etc/yum.conf, and that its value is 1:
plugins=1
You can disable all plug-ins by changing this line to plugins=0.

Important

Disabling all plug-ins is not advised because certain plug-ins provide important yum services. In particular, the product-id and subscription-manager plug-ins provide support for the certificate-based Content Delivery Network (CDN). Disabling plug-ins globally is provided as a convenience option, and is generally only recommended when diagnosing a potential problem with yum.
Every installed plug-in has its own configuration file in the /etc/yum/pluginconf.d/ directory. You can set plug-in specific options in these files. For example, here is the aliases plug-in's aliases.conf configuration file:
[main]
enabled=1
Similar to the /etc/yum.conf file, the plug-in configuration files always contain a [main] section where the enabled= option controls whether the plug-in is enabled when you run yum commands. If this option is missing, you can add it manually to the file.
If you disable all plug-ins by setting enabled=0 in /etc/yum.conf, then all plug-ins are disabled regardless of whether they are enabled in their individual configuration files.
If you merely want to disable all yum plug-ins for a single yum command, use the --noplugins option.
If you want to disable one or more yum plug-ins for a single yum command, add the --disableplugin=plugin_name option to the command. For example, to disable the aliases plug-in while updating a system, type:
~]# yum update --disableplugin=aliases
The plug-in names you provide to the --disableplugin= option are the same names listed after the Loaded plugins line in the output of any yum command. You can disable multiple plug-ins by separating their names with commas. In addition, you can match multiple plug-in names or shorten long ones by using glob expressions:
~]# yum update --disableplugin=aliases,lang*

8.6.2. Installing Additional Yum Plug-ins

Yum plug-ins usually adhere to the yum-plugin-plugin_name package-naming convention, but not always: the package which provides the kabi plug-in is named kabi-yum-plugins, for example. You can install a yum plug-in in the same way you install other packages. For instance, to install the yum-aliases plug-in, type the following at a shell prompt:
~]# yum install yum-plugin-aliases

8.6.3. Working with Yum Plug-ins

The following list provides descriptions and usage instructions for several useful yum plug-ins. Plug-ins are listed by names, brackets contain the name of the package.
search-disabled-repos (subscription-manager)
The search-disabled-repos plug-in allows you to temporarily or permanently enable disabled repositories to help resolve dependencies. With this plug-in enabled, when Yum fails to install a package due to failed dependency resolution, it offers to temporarily enable disabled repositories and try again. If the installation succeeds, Yum also offers to enable the used repositories permanently. Note that the plug-in works only with the repositories that are managed by subscription-manager and not with custom repositories.

Important

If yum is executed with the --assumeyes or -y option, or if the assumeyes directive is enabled in /etc/yum.conf, the plug-in enables disabled repositories, both temporarily and permanently, without prompting for confirmation. This may lead to problems, for example, enabling repositories that you do not want enabled.
To configure the search-disabled-repos plug-in, edit the configuration file located in /etc/yum/pluginconf.d/search-disabled-repos.conf. For the list of directives you can use in the [main] section, see the table below.

Table 8.3. Supported search-disabled-repos.conf directives

Directive Description
enabled=value Allows you to enable or disable the plug-in. The value must be either 1 (enabled), or 0 (disabled). The plug-in is enabled by default.
notify_only=value Allows you to restrict the behavior of the plug-in to notifications only. The value must be either 1 (notify only without modifying the behavior of Yum), or 0 (modify the behavior of Yum). By default the plug-in only notifies the user.
ignored_repos=repositories Allows you to specify the repositories that will not be enabled by the plug-in.
kabi (kabi-yum-plugins)
The kabi plug-in checks whether a driver update package conforms with the official Red Hat kernel Application Binary Interface (kABI). With this plug-in enabled, when a user attempts to install a package that uses kernel symbols which are not on a whitelist, a warning message is written to the system log. Additionally, configuring the plug-in to run in enforcing mode prevents such packages from being installed at all.
To configure the kabi plug-in, edit the configuration file located in /etc/yum/pluginconf.d/kabi.conf. A list of directives that can be used in the [main] section is shown in the table below.

Table 8.4. Supported kabi.conf directives

Directive Description
enabled=value Allows you to enable or disable the plug-in. The value must be either 1 (enabled), or 0 (disabled). When installed, the plug-in is enabled by default.
whitelists=directory Allows you to specify the directory in which the files with supported kernel symbols are located. By default, the kabi plug-in uses files provided by the kernel-abi-whitelists package (that is, the /usr/lib/modules/kabi-rhel70/ directory).
enforce=value Allows you to enable or disable enforcing mode. The value must be either 1 (enabled), or 0 (disabled). By default, this option is commented out and the kabi plug-in only displays a warning message.
product-id (subscription-manager)
The product-id plug-in manages product identity certificates for products installed from the Content Delivery Network. The product-id plug-in is installed by default.
langpacks (yum-langpacks)
The langpacks plug-in is used to search for locale packages of a selected language for every package that is installed. The langpacks plug-in is installed by default.
aliases (yum-plugin-aliases)
The aliases plug-in adds the alias command-line option which enables configuring and using aliases for yum commands.
yum-changelog (yum-plugin-changelog)
The yum-changelog plug-in adds the --changelog command-line option that enables viewing package change logs before and after updating.
yum-tmprepo (yum-plugin-tmprepo)
The yum-tmprepo plug-in adds the --tmprepo command-line option that takes the URL of a repository file, downloads and enables it for only one transaction. This plug-in tries to ensure the safe temporary usage of repositories. By default, it does not allow to disable the gpg check.
yum-verify (yum-plugin-verify)
The yum-verify plug-in adds the verify, verify-rpm, and verify-all command-line options for viewing verification data on the system.
yum-versionlock (yum-plugin-versionlock)
The yum-versionlock plug-in excludes other versions of selected packages, which enables protecting packages from being updated by newer versions. With the versionlock command-line option, you can view and edit the list of locked packages.

8.7. Additional Resources

For more information on how to manage software packages on Red Hat Enterprise Linux, see the resources listed below.

Installed Documentation

  • yum(8) — The manual page for the yum command-line utility provides a complete list of supported options and commands.
  • yumdb(8) — The manual page for the yumdb command-line utility documents how to use this tool to query and, if necessary, alter the yum database.
  • yum.conf(5) — The manual page named yum.conf documents available yum configuration options.
  • yum-utils(1) — The manual page named yum-utils lists and briefly describes additional utilities for managing yum configuration, manipulating repositories, and working with yum database.

Online Resources

  • Yum Guides — The Yum Guides page on the project home page provides links to further documentation.
  • Red Hat Customer Portal Labs — The Red Hat Customer Portal Labs includes a Yum Repository Configuration Helper.

See Also

  • Chapter 5, Gaining Privileges documents how to gain administrative privileges by using the su and sudo commands.
  • Appendix A, RPM describes the RPM Package Manager (RPM), the packaging system used by Red Hat Enterprise Linux.

Part IV. Infrastructure Services

This part provides information on how to configure services and daemons and enable remote access to a Red Hat Enterprise Linux machine.

Chapter 9. Managing Services with systemd

9.1. Introduction to systemd

Systemd is a system and service manager for Linux operating systems. It is designed to be backwards compatible with SysV init scripts, and provides a number of features such as parallel startup of system services at boot time, on-demand activation of daemons, support for system state snapshots, or dependency-based service control logic. In Red Hat Enterprise Linux 7, systemd replaces Upstart as the default init system.
Systemd introduces the concept of systemd units. These units are represented by unit configuration files located in one of the directories listed in Table 9.2, “Systemd Unit Files Locations”, and encapsulate information about system services, listening sockets, saved system state snapshots, and other objects that are relevant to the init system. For a complete list of available systemd unit types, see Table 9.1, “Available systemd Unit Types”.

Table 9.1. Available systemd Unit Types

Unit TypeFile ExtensionDescription
Service unit .service A system service.
Target unit .target A group of systemd units.
Automount unit .automount A file system automount point.
Device unit .device A device file recognized by the kernel.
Mount unit .mount A file system mount point.
Path unit .path A file or directory in a file system.
Scope unit .scope An externally created process.
Slice unit .slice A group of hierarchically organized units that manage system processes.
Snapshot unit .snapshot A saved state of the systemd manager.
Socket unit .socket An inter-process communication socket.
Swap unit .swap A swap device or a swap file.
Timer unit .timer A systemd timer.

Table 9.2. Systemd Unit Files Locations

DirectoryDescription
/usr/lib/systemd/system/ Systemd unit files distributed with installed RPM packages.
/run/systemd/system/ Systemd unit files created at run time. This directory takes precedence over the directory with installed service unit files.
/etc/systemd/system/ Systemd unit files created by systemctl enable as well as unit files added for extending a service. This directory takes precedence over the directory with runtime unit files.

Overriding the Default systemd Configuration Using system.conf

The default configuration of systemd is defined during the compilation and it can be found in systemd configuration file at /etc/systemd/system.conf. Use this file if you want to deviate from those defaults and override selected default values for systemd units globally.
For example, to override the default value of the timeout limit, which is set to 90 seconds, use the DefaultTimeoutStartSec parameter to input the required value in seconds.
DefaultTimeoutStartSec=required value

9.1.1. Main Features

In Red Hat Enterprise Linux 7, the systemd system and service manager provides the following main features:
  • Socket-based activation — At boot time, systemd creates listening sockets for all system services that support this type of activation, and passes the sockets to these services as soon as they are started. This not only allows systemd to start services in parallel, but also makes it possible to restart a service without losing any message sent to it while it is unavailable: the corresponding socket remains accessible and all messages are queued.
    Systemd uses socket units for socket-based activation.
  • Bus-based activation — System services that use D-Bus for inter-process communication can be started on-demand the first time a client application attempts to communicate with them. Systemd uses D-Bus service files for bus-based activation.
  • Device-based activation — System services that support device-based activation can be started on-demand when a particular type of hardware is plugged in or becomes available. Systemd uses device units for device-based activation.
  • Path-based activation — System services that support path-based activation can be started on-demand when a particular file or directory changes its state. Systemd uses path units for path-based activation.
  • System state snapshots — Systemd can temporarily save the current state of all units or restore a previous state of the system from a dynamically created snapshot. To store the current state of the system, systemd uses dynamically created snapshot units.
  • Mount and automount point management — Systemd monitors and manages mount and automount points. Systemd uses mount units for mount points and automount units for automount points.
  • Aggressive parallelization — Because of the use of socket-based activation, systemd can start system services in parallel as soon as all listening sockets are in place. In combination with system services that support on-demand activation, parallel activation significantly reduces the time required to boot the system.
  • Transactional unit activation logic — Before activating or deactivating a unit, systemd calculates its dependencies, creates a temporary transaction, and verifies that this transaction is consistent. If a transaction is inconsistent, systemd automatically attempts to correct it and remove non-essential jobs from it before reporting an error.
  • Backwards compatibility with SysV init — Systemd supports SysV init scripts as described in the Linux Standard Base Core Specification, which eases the upgrade path to systemd service units.

9.1.2. Compatibility Changes

The systemd system and service manager is designed to be mostly compatible with SysV init and Upstart. The following are the most notable compatibility changes with regards to the previous major release of the Red Hat Enterprise Linux system:
  • Systemd has only limited support for runlevels. It provides a number of target units that can be directly mapped to these runlevels and for compatibility reasons, it is also distributed with the earlier runlevel command. Not all systemd targets can be directly mapped to runlevels, however, and as a consequence, this command might return N to indicate an unknown runlevel. It is recommended that you avoid using the runlevel command if possible.
    For more information about systemd targets and their comparison with runlevels, see Section 9.3, “Working with systemd Targets”.
  • The systemctl utility does not support custom commands. In addition to standard commands such as start, stop, and status, authors of SysV init scripts could implement support for any number of arbitrary commands in order to provide additional functionality. For example, the init script for iptables in Red Hat Enterprise Linux 6 could be executed with the panic command, which immediately enabled panic mode and reconfigured the system to start dropping all incoming and outgoing packets. This is not supported in systemd and the systemctl only accepts documented commands.
    For more information about the systemctl utility and its comparison with the earlier service utility, see Section 9.2, “Managing System Services”.
  • The systemctl utility does not communicate with services that have not been started by systemd. When systemd starts a system service, it stores the ID of its main process in order to keep track of it. The systemctl utility then uses this PID to query and manage the service. Consequently, if a user starts a particular daemon directly on the command line, systemctl is unable to determine its current status or stop it.
  • Systemd stops only running services. Previously, when the shutdown sequence was initiated, Red Hat Enterprise Linux 6 and earlier releases of the system used symbolic links located in the /etc/rc0.d/ directory to stop all available system services regardless of their status. With systemd, only running services are stopped on shutdown.
  • System services are unable to read from the standard input stream. When systemd starts a service, it connects its standard input to /dev/null to prevent any interaction with the user.
  • System services do not inherit any context (such as the HOME and PATH environment variables) from the invoking user and their session. Each service runs in a clean execution context.
  • When loading a SysV init script, systemd reads dependency information encoded in the Linux Standard Base (LSB) header and interprets it at run time.
  • All operations on service units are subject to a default timeout of 5 minutes to prevent a malfunctioning service from freezing the system. This value is hardcoded for services that are generated from initscripts and cannot be changed. However, individual configuration files can be used to specify a longer timeout value per service, see Example 9.21, “Changing the timeout limit”
For a detailed list of compatibility changes introduced with systemd, see the Migration Planning Guide for Red Hat Enterprise Linux 7.

9.2. Managing System Services

Note

To expand your expertise, you might also be interested in the Red Hat System Administration II (RH134) training course.
Previous versions of Red Hat Enterprise Linux, which were distributed with SysV init or Upstart, used init scripts located in the /etc/rc.d/init.d/ directory. These init scripts were typically written in Bash, and allowed the system administrator to control the state of services and daemons in their system. In Red Hat Enterprise Linux 7, these init scripts have been replaced with service units.
Service units end with the .service file extension and serve a similar purpose as init scripts. To view, start, stop, restart, enable, or disable system services, use the systemctl command as described in Table 9.3, “Comparison of the service Utility with systemctl ”, Table 9.4, “Comparison of the chkconfig Utility with systemctl”, and further in this section. The service and chkconfig commands are still available in the system and work as expected, but are only included for compatibility reasons and should be avoided.

Table 9.3. Comparison of the service Utility with systemctl

servicesystemctlDescription
service name start
systemctl start name.service
Starts a service.
service name stop
systemctl stop name.service
Stops a service.
service name restart
systemctl restart name.service
Restarts a service.
service name condrestart
systemctl try-restart name.service
Restarts a service only if it is running.
service name reload
systemctl reload name.service
Reloads configuration.
service name status
systemctl status name.service
systemctl is-active name.service
Checks if a service is running.
service --status-all
systemctl list-units --type service --all
Displays the status of all services.

Table 9.4. Comparison of the chkconfig Utility with systemctl

chkconfigsystemctlDescription
chkconfig name on
systemctl enable name.service
Enables a service.
chkconfig name off
systemctl disable name.service
Disables a service.
chkconfig --list name
systemctl status name.service
systemctl is-enabled name.service
Checks if a service is enabled.
chkconfig --list
systemctl list-unit-files --type service
Lists all services and checks if they are enabled.
chkconfig --list
systemctl list-dependencies --after
Lists services that are ordered to start before the specified unit.
chkconfig --list
systemctl list-dependencies --before
Lists services that are ordered to start after the specified unit.

Specifying Service Units

For clarity, all command examples in the rest of this section use full unit names with the .service file extension, for example:
~]# systemctl stop nfs-server.service
However, the file extension can be omitted, in which case the systemctl utility assumes the argument is a service unit. The following command is equivalent to the one above:
~]# systemctl stop nfs-server
Additionally, some units have alias names. Those names can have shorter names than units, which can be used instead of the actual unit names. To find all aliases that can be used for a particular unit, use:
~]# systemctl show nfs-server.service -p Names

Behavior of systemctl in a chroot Environment

If you change the root directory using the chroot command, most systemctl commands refuse to perform any action. The reason for this is that the systemd process and the user that used the chroot command do not have the same view of the filesystem. This happens, for example, when systemctl is invoked from a kickstart file.
The exception to this are unit file commands such as the systemctl enable and systemctl disable commands. These commands do not need a running system and do not affect running processes, but they do affect unit files. Therefore, you can run these commands even in chroot environment. For example, to enable the httpd service on a system under the /srv/website1/ directory:
~]# chroot /srv/website1
~]# systemctl enable httpd.service
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service, pointing to /usr/lib/systemd/system/httpd.service.

9.2.1. Listing Services

To list all currently loaded service units, type the following at a shell prompt:
systemctl list-units --type service
For each service unit file, this command displays its full name (UNIT) followed by a note whether the unit file has been loaded (LOAD), its high-level (ACTIVE) and low-level (SUB) unit file activation state, and a short description (DESCRIPTION).
By default, the systemctl list-units command displays only active units. If you want to list all loaded units regardless of their state, run this command with the --all or -a command line option:
systemctl list-units --type service --all
You can also list all available service units to see if they are enabled. To do so, type:
systemctl list-unit-files --type service
For each service unit, this command displays its full name (UNIT FILE) followed by information whether the service unit is enabled or not (STATE). For information on how to determine the status of individual service units, see Section 9.2.2, “Displaying Service Status”.

Example 9.1. Listing Services

To list all currently loaded service units, run the following command:
~]$ systemctl list-units --type service
UNIT                           LOAD   ACTIVE SUB     DESCRIPTION
abrt-ccpp.service              loaded active exited  Install ABRT coredump hook
abrt-oops.service              loaded active running ABRT kernel log watcher
abrt-vmcore.service            loaded active exited  Harvest vmcores for ABRT
abrt-xorg.service              loaded active running ABRT Xorg log watcher
abrtd.service                  loaded active running ABRT Automated Bug Reporting Tool
...
systemd-vconsole-setup.service loaded active exited  Setup Virtual Console
tog-pegasus.service            loaded active running OpenPegasus CIM Server

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

46 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'
To list all installed service unit files to determine if they are enabled, type:
~]$ systemctl list-unit-files --type service
UNIT FILE                                   STATE
abrt-ccpp.service                           enabled
abrt-oops.service                           enabled
abrt-vmcore.service                         enabled
abrt-xorg.service                           enabled
abrtd.service                               enabled
...
wpa_supplicant.service                      disabled
ypbind.service                              disabled

208 unit files listed.

9.2.2. Displaying Service Status

To display detailed information about a service unit that corresponds to a system service, type the following at a shell prompt:
systemctl status name.service
Replace name with the name of the service unit you want to inspect (for example, gdm). This command displays the name of the selected service unit followed by its short description, one or more fields described in Table 9.5, “Available Service Unit Information”, and if it is executed by the root user, also the most recent log entries.

Table 9.5. Available Service Unit Information

FieldDescription
Loaded Information whether the service unit has been loaded, the absolute path to the unit file, and a note whether the unit is enabled.
Active Information whether the service unit is running followed by a time stamp.
Main PID The PID of the corresponding system service followed by its name.
Status Additional information about the corresponding system service.
Process Additional information about related processes.
CGroup Additional information about related Control Groups (cgroups).
To only verify that a particular service unit is running, run the following command:
systemctl is-active name.service
Similarly, to determine whether a particular service unit is enabled, type:
systemctl is-enabled name.service
Note that both systemctl is-active and systemctl is-enabled return an exit status of 0 if the specified service unit is running or enabled. For information on how to list all currently loaded service units, see Section 9.2.1, “Listing Services”.

Example 9.2. Displaying Service Status

The service unit for the GNOME Display Manager is named gdm.service. To determine the current status of this service unit, type the following at a shell prompt:
~]# systemctl status gdm.service
gdm.service - GNOME Display Manager
   Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled)
   Active: active (running) since Thu 2013-10-17 17:31:23 CEST; 5min ago
 Main PID: 1029 (gdm)
   CGroup: /system.slice/gdm.service
           ├─1029 /usr/sbin/gdm
           ├─1037 /usr/libexec/gdm-simple-slave --display-id /org/gno...
           └─1047 /usr/bin/Xorg :0 -background none -verbose -auth /r...

Oct 17 17:31:23 localhost systemd[1]: Started GNOME Display Manager.

Example 9.3. Displaying Services Ordered to Start Before a Service

To determine what services are ordered to start before the specified service, type the following at a shell prompt:
~]# systemctl list-dependencies --after gdm.service
gdm.service
├─dbus.socket
├─getty@tty1.service
├─livesys.service
├─plymouth-quit.service
├─system.slice
├─systemd-journald.socket
├─systemd-user-sessions.service
└─basic.target
[output truncated]

Example 9.4. Displaying Services Ordered to Start After a Service

To determine what services are ordered to start after the specified service, type the following at a shell prompt:
~]# systemctl list-dependencies --before gdm.service
gdm.service
├─dracut-shutdown.service
├─graphical.target
│ ├─systemd-readahead-done.service
│ ├─systemd-readahead-done.timer
│ └─systemd-update-utmp-runlevel.service
└─shutdown.target
  ├─systemd-reboot.service
  └─final.target
    └─systemd-reboot.service

9.2.3. Starting a Service

To start a service unit that corresponds to a system service, type the following at a shell prompt as root:
systemctl start name.service
Replace name with the name of the service unit you want to start (for example, gdm). This command starts the selected service unit in the current session. For information on how to enable a service unit to be started at boot time, see Section 9.2.6, “Enabling a Service”. For information on how to determine the status of a certain service unit, see Section 9.2.2, “Displaying Service Status”.

Example 9.5. Starting a Service

The service unit for the Apache HTTP Server is named httpd.service. To activate this service unit and start the httpd daemon in the current session, run the following command as root:
~]# systemctl start httpd.service

9.2.4. Stopping a Service

To stop a service unit that corresponds to a system service, type the following at a shell prompt as root:
systemctl stop name.service
Replace name with the name of the service unit you want to stop (for example, bluetooth). This command stops the selected service unit in the current session. For information on how to disable a service unit and prevent it from being started at boot time, see Section 9.2.7, “Disabling a Service”. For information on how to determine the status of a certain service unit, see Section 9.2.2, “Displaying Service Status”.

Example 9.6. Stopping a Service

The service unit for the bluetoothd daemon is named bluetooth.service. To deactivate this service unit and stop the bluetoothd daemon in the current session, run the following command as root:
~]# systemctl stop bluetooth.service

9.2.5. Restarting a Service

To restart a service unit that corresponds to a system service, type the following at a shell prompt as root:
systemctl restart name.service
Replace name with the name of the service unit you want to restart (for example, httpd). This command stops the selected service unit in the current session and immediately starts it again. Importantly, if the selected service unit is not running, this command starts it too. To tell systemd to restart a service unit only if the corresponding service is already running, run the following command as root:
systemctl try-restart name.service
Certain system services also allow you to reload their configuration without interrupting their execution. To do so, type as root:
systemctl reload name.service
Note that system services that do not support this feature ignore this command altogether. For convenience, the systemctl command also supports the reload-or-restart and reload-or-try-restart commands that restart such services instead. For information on how to determine the status of a certain service unit, see Section 9.2.2, “Displaying Service Status”.

Example 9.7. Restarting a Service

In order to prevent users from encountering unnecessary error messages or partially rendered web pages, the Apache HTTP Server allows you to edit and reload its configuration without the need to restart it and interrupt actively processed requests. To do so, type the following at a shell prompt as root:
~]# systemctl reload httpd.service

9.2.6. Enabling a Service

To configure a service unit that corresponds to a system service to be automatically started at boot time, type the following at a shell prompt as root:
systemctl enable name.service
Replace name with the name of the service unit you want to enable (for example, httpd). This command reads the [Install] section of the selected service unit and creates appropriate symbolic links to the /usr/lib/systemd/system/name.service file in the /etc/systemd/system/ directory and its subdirectories. This command does not, however, rewrite links that already exist. If you want to ensure that the symbolic links are re-created, use the following command as root:
systemctl reenable name.service
This command disables the selected service unit and immediately enables it again. For information on how to determine whether a certain service unit is enabled to start at boot time, see Section 9.2.2, “Displaying Service Status”. For information on how to start a service in the current session, see Section 9.2.3, “Starting a Service”.

Example 9.8. Enabling a Service

To configure the Apache HTTP Server to start automatically at boot time, run the following command as root:
~]# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

9.2.7. Disabling a Service

To prevent a service unit that corresponds to a system service from being automatically started at boot time, type the following at a shell prompt as root:
systemctl disable name.service
Replace name with the name of the service unit you want to disable (for example, bluetooth). This command reads the [Install] section of the selected service unit and removes appropriate symbolic links to the /usr/lib/systemd/system/name.service file from the /etc/systemd/system/ directory and its subdirectories. In addition, you can mask any service unit to prevent it from being started manually or by another service. To do so, run the following command as root:
systemctl mask name.service
This command replaces the /etc/systemd/system/name.service file with a symbolic link to /dev/null, rendering the actual unit file inaccessible to systemd. To revert this action and unmask a service unit, type as root:
systemctl unmask name.service
For information on how to determine whether a certain service unit is enabled to start at boot time, see Section 9.2.2, “Displaying Service Status”. For information on how to stop a service in the current session, see Section 9.2.4, “Stopping a Service”.

Example 9.9. Disabling a Service

Example 9.6, “Stopping a Service” illustrates how to stop the bluetooth.service unit in the current session. To prevent this service unit from starting at boot time, type the following at a shell prompt as root:
~]# systemctl disable bluetooth.service
Removed symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service.
Removed symlink /etc/systemd/system/dbus-org.bluez.service.

9.2.8. Starting a Conflicting Service

In systemd, positive and negative dependencies between services exist. Starting particular service may require starting one or more other services (positive dependency) or stopping one or more services (negative dependency).
When you attempt to start a new service, systemd resolves all dependencies automatically. Note that this is done without explicit notification to the user. If you are already running a service, and you attempt to start another service with a negative dependency, the first service is automatically stopped.
For example, if you are running the postfix service, and you try to start the sendmail service, systemd first automatically stops postfix, because these two services are conflicting and cannot run on the same port.

9.3. Working with systemd Targets

Previous versions of Red Hat Enterprise Linux, which were distributed with SysV init or Upstart, implemented a predefined set of runlevels that represented specific modes of operation. These runlevels were numbered from 0 to 6 and were defined by a selection of system services to be run when a particular runlevel was enabled by the system administrator. In Red Hat Enterprise Linux 7, the concept of runlevels has been replaced with systemd targets.
Systemd targets are represented by target units. Target units end with the .target file extension and their only purpose is to group together other systemd units through a chain of dependencies. For example, the graphical.target unit, which is used to start a graphical session, starts system services such as the GNOME Display Manager (gdm.service) or Accounts Service (accounts-daemon.service) and also activates the multi-user.target unit. Similarly, the multi-user.target unit starts other essential system services such as NetworkManager (NetworkManager.service) or D-Bus (dbus.service) and activates another target unit named basic.target.
Red Hat Enterprise Linux 7 is distributed with a number of predefined targets that are more or less similar to the standard set of runlevels from the previous releases of this system. For compatibility reasons, it also provides aliases for these targets that directly map them to SysV runlevels. Table 9.6, “Comparison of SysV Runlevels with systemd Targets” provides a complete list of SysV runlevels and their corresponding systemd targets.

Table 9.6. Comparison of SysV Runlevels with systemd Targets

RunlevelTarget UnitsDescription
0 runlevel0.target, poweroff.target Shut down and power off the system.
1 runlevel1.target, rescue.target Set up a rescue shell.
2 runlevel2.target, multi-user.target Set up a non-graphical multi-user system.
3 runlevel3.target, multi-user.target Set up a non-graphical multi-user system.
4 runlevel4.target, multi-user.target Set up a non-graphical multi-user system.
5 runlevel5.target, graphical.target Set up a graphical multi-user system.
6 runlevel6.target, reboot.target Shut down and reboot the system.
To view, change, or configure systemd targets, use the systemctl utility as described in Table 9.7, “Comparison of SysV init Commands with systemctl” and in the sections below. The runlevel and telinit commands are still available in the system and work as expected, but are only included for compatibility reasons and should be avoided.

Table 9.7. Comparison of SysV init Commands with systemctl

Old CommandNew CommandDescription
runlevel systemctl list-units --type target Lists currently loaded target units.
telinit runlevel systemctl isolate name.target Changes the current target.

9.3.1. Viewing the Default Target

To determine which target unit is used by default, run the following command:
systemctl get-default
This command resolves the symbolic link located at /etc/systemd/system/default.target and displays the result. For information on how to change the default target, see Section 9.3.3, “Changing the Default Target”. For information on how to list all currently loaded target units, see Section 9.3.2, “Viewing the Current Target”.

Example 9.10. Viewing the Default Target

To display the default target unit, type:
~]$ systemctl get-default
graphical.target

9.3.2. Viewing the Current Target

To list all currently loaded target units, type the following command at a shell prompt:
systemctl list-units --type target
For each target unit, this commands displays its full name (UNIT) followed by a note whether the unit has been loaded (LOAD), its high-level (ACTIVE) and low-level (SUB) unit activation state, and a short description (DESCRIPTION).
By default, the systemctl list-units command displays only active units. If you want to list all loaded units regardless of their state, run this command with the --all or -a command line option:
systemctl list-units --type target --all
See Section 9.3.1, “Viewing the Default Target” for information on how to display the default target. For information on how to change the current target, see Section 9.3.4, “Changing the Current Target”.

Example 9.11. Viewing the Current Target

To list all currently loaded target units, run the following command:
~]$ systemctl list-units --type target
UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
basic.target          loaded active active Basic System
cryptsetup.target     loaded active active Encrypted Volumes
getty.target          loaded active active Login Prompts
graphical.target      loaded active active Graphical Interface
local-fs-pre.target   loaded active active Local File Systems (Pre)
local-fs.target       loaded active active Local File Systems
multi-user.target     loaded active active Multi-User System
network.target        loaded active active Network
paths.target          loaded active active Paths
remote-fs.target      loaded active active Remote File Systems
sockets.target        loaded active active Sockets
sound.target          loaded active active Sound Card
spice-vdagentd.target loaded active active Agent daemon for Spice guests
swap.target           loaded active active Swap
sysinit.target        loaded active active System Initialization
time-sync.target      loaded active active System Time Synchronized
timers.target         loaded active active Timers

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

17 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

9.3.3. Changing the Default Target

To configure the system to use a different target unit by default, type the following at a shell prompt as root:
systemctl set-default name.target
Replace name with the name of the target unit you want to use by default (for example, multi-user). This command replaces the /etc/systemd/system/default.target file with a symbolic link to /usr/lib/systemd/system/name.target, where name is the name of the target unit you want to use. For information on how to change the current target, see Section 9.3.4, “Changing the Current Target”. For information on how to list all currently loaded target units, see Section 9.3.2, “Viewing the Current Target”.

Example 9.12. Changing the Default Target

To configure the system to use the multi-user.target unit by default, run the following command as root:
~]# systemctl set-default multi-user.target
rm '/etc/systemd/system/default.target'
ln -s '/usr/lib/systemd/system/multi-user.target' '/etc/systemd/system/default.target'

9.3.4. Changing the Current Target

To change to a different target unit in the current session, type the following at a shell prompt as root:
systemctl isolate name.target
Replace name with the name of the target unit you want to use (for example, multi-user). This command starts the target unit named name and all dependent units, and immediately stops all others. For information on how to change the default target, see Section 9.3.3, “Changing the Default Target”. For information on how to list all currently loaded target units, see Section 9.3.2, “Viewing the Current Target”.

Example 9.13. Changing the Current Target

To turn off the graphical user interface and change to the multi-user.target unit in the current session, run the following command as root:
~]# systemctl isolate multi-user.target

9.3.5. Changing to Rescue Mode

Rescue mode provides a convenient single-user environment and allows you to repair your system in situations when it is unable to complete a regular booting process. In rescue mode, the system attempts to mount all local file systems and start some important system services, but it does not activate network interfaces or allow more users to be logged into the system at the same time. In Red Hat Enterprise Linux 7, rescue mode is equivalent to single user mode and requires the root password.
To change the current target and enter rescue mode in the current session, type the following at a shell prompt as root:
systemctl rescue
This command is similar to systemctl isolate rescue.target, but it also sends an informative message to all users that are currently logged into the system. To prevent systemd from sending this message, run this command with the --no-wall command line option:
systemctl --no-wall rescue
For information on how to enter emergency mode, see Section 9.3.6, “Changing to Emergency Mode”.

Example 9.14. Changing to Rescue Mode

To enter rescue mode in the current session, run the following command as root:
~]# systemctl rescue

Broadcast message from root@localhost on pts/0 (Fri 2013-10-25 18:23:15 CEST):

The system is going down to rescue mode NOW!

9.3.6. Changing to Emergency Mode

Emergency mode provides the most minimal environment possible and allows you to repair your system even in situations when the system is unable to enter rescue mode. In emergency mode, the system mounts the root file system only for reading, does not attempt to mount any other local file systems, does not activate network interfaces, and only starts a few essential services. In Red Hat Enterprise Linux 7, emergency mode requires the root password.
To change the current target and enter emergency mode, type the following at a shell prompt as root:
systemctl emergency
This command is similar to systemctl isolate emergency.target, but it also sends an informative message to all users that are currently logged into the system. To prevent systemd from sending this message, run this command with the --no-wall command line option:
systemctl --no-wall emergency
For information on how to enter rescue mode, see Section 9.3.5, “Changing to Rescue Mode”.

Example 9.15. Changing to Emergency Mode

To enter emergency mode without sending a message to all users that are currently logged into the system, run the following command as root:
~]# systemctl --no-wall emergency

9.4. Shutting Down, Suspending, and Hibernating the System

In Red Hat Enterprise Linux 7, the systemctl utility replaces a number of power management commands used in previous versions of the Red Hat Enterprise Linux system. The commands listed in Table 9.8, “Comparison of Power Management Commands with systemctl” are still available in the system for compatibility reasons, but it is advised that you use systemctl when possible.

Table 9.8. Comparison of Power Management Commands with systemctl

Old CommandNew CommandDescription
halt systemctl halt Halts the system.
poweroff systemctl poweroff Powers off the system.
reboot systemctl reboot Restarts the system.
pm-suspend systemctl suspend Suspends the system.
pm-hibernate systemctl hibernate Hibernates the system.
pm-suspend-hybrid systemctl hybrid-sleep Hibernates and suspends the system.

9.4.1. Shutting Down the System

The systemctl utility provides commands for shutting down the system, however the traditional shutdown command is also supported. Although the shutdown command will call the systemctl utility to perform the shutdown, it has an advantage in that it also supports a time argument. This is particularly useful for scheduled maintenance and to allow more time for users to react to the warning that a system shutdown has been scheduled. The option to cancel the shutdown can also be an advantage.

Using systemctl Commands

To shut down the system and power off the machine, type the following at a shell prompt as root:
systemctl poweroff
To shut down and halt the system without powering off the machine, run the following command as root:
systemctl halt
By default, running either of these commands causes systemd to send an informative message to all users that are currently logged into the system. To prevent systemd from sending this message, run the selected command with the --no-wall command line option, for example:
systemctl --no-wall poweroff

Using the shutdown Command

To shut down the system and power off the machine at a certain time, use a command in the following format as root:
shutdown --poweroff hh:mm
Where hh:mm is the time in 24 hour clock format. The /run/nologin file is created 5 minutes before system shutdown to prevent new logins. When a time argument is used, an optional message, the wall message, can be appended to the command.
To shut down and halt the system after a delay, without powering off the machine, use a command in the following format as root:
shutdown --halt +m
Where +m is the delay time in minutes. The now keyword is an alias for +0.
A pending shutdown can be canceled by the root user as follows:
shutdown -c
See the shutdown(8) manual page for further command options.

9.4.2. Restarting the System

To restart the system, run the following command as root:
systemctl reboot
By default, this command causes systemd to send an informative message to all users that are currently logged into the system. To prevent systemd from sending this message, run this command with the --no-wall command line option:
systemctl --no-wall reboot

9.4.3. Suspending the System

To suspend the system, type the following at a shell prompt as root:
systemctl suspend
This command saves the system state in RAM and with the exception of the RAM module, powers off most of the devices in the machine. When you turn the machine back on, the system then restores its state from RAM without having to boot again. Because the system state is saved in RAM and not on the hard disk, restoring the system from suspend mode is significantly faster than restoring it from hibernation, but as a consequence, a suspended system state is also vulnerable to power outages.
For information on how to hibernate the system, see Section 9.4.4, “Hibernating the System”.

9.4.4. Hibernating the System

To hibernate the system, type the following at a shell prompt as root:
systemctl hibernate
This command saves the system state on the hard disk drive and powers off the machine. When you turn the machine back on, the system then restores its state from the saved data without having to boot again. Because the system state is saved on the hard disk and not in RAM, the machine does not have to maintain electrical power to the RAM module, but as a consequence, restoring the system from hibernation is significantly slower than restoring it from suspend mode.
To hibernate and suspend the system, run the following command as root:
systemctl hybrid-sleep
For information on how to suspend the system, see Section 9.4.3, “Suspending the System”.

9.5. Controlling systemd on a Remote Machine

In addition to controlling the systemd system and service manager locally, the systemctl utility also allows you to interact with systemd running on a remote machine over the SSH protocol. Provided that the sshd service on the remote machine is running, you can connect to this machine by running the systemctl command with the --host or -H command line option:
systemctl --host user_name@host_name command
Replace user_name with the name of the remote user, host_name with the machine's host name, and command with any of the systemctl commands described above. Note that the remote machine must be configured to allow the selected user remote access over the SSH protocol. For more information on how to configure an SSH server, see Chapter 11, OpenSSH.

Example 9.16. Remote Management

To log in to a remote machine named server-01.example.com as the root user and determine the current status of the httpd.service unit, type the following at a shell prompt:
~]$ systemctl -H root@server-01.example.com status httpd.service
>>>>>>> systemd unit files -- update
root@server-01.example.com's password:
httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled)
   Active: active (running) since Fri 2013-11-01 13:58:56 CET; 2h 48min ago
 Main PID: 649
   Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"
   CGroup: /system.slice/httpd.service

9.6. Creating and Modifying systemd Unit Files

A unit file contains configuration directives that describe the unit and define its behavior. Several systemctl commands work with unit files in the background. To make finer adjustments, system administrator must edit or create unit files manually. Table 9.2, “Systemd Unit Files Locations” lists three main directories where unit files are stored on the system, the /etc/systemd/system/ directory is reserved for unit files created or customized by the system administrator.
Unit file names take the following form:
unit_name.type_extension
Here, unit_name stands for the name of the unit and type_extension identifies the unit type, see Table 9.1, “Available systemd Unit Types” for a complete list of unit types. For example, there usually is sshd.service as well as sshd.socket unit present on your system.
Unit files can be supplemented with a directory for additional configuration files. For example, to add custom configuration options to sshd.service, create the sshd.service.d/custom.conf file and insert additional directives there. For more information on configuration directories, see Section 9.6.4, “Modifying Existing Unit Files”.
Also, the sshd.service.wants/ and sshd.service.requires/ directories can be created. These directories contain symbolic links to unit files that are dependencies of the sshd service. The symbolic links are automatically created either during installation according to [Install] unit file options (see Table 9.11, “Important [Install] Section Options”) or at runtime based on [Unit] options (see Table 9.9, “Important [Unit] Section Options”). It is also possible to create these directories and symbolic links manually.
Many unit file options can be set using the so called unit specifiers – wildcard strings that are dynamically replaced with unit parameters when the unit file is loaded. This enables creation of generic unit files that serve as templates for generating instantiated units. See Section 9.6.5, “Working with Instantiated Units” for details.

9.6.1. Understanding the Unit File Structure

Unit files typically consist of three sections:

Table 9.9. Important [Unit] Section Options

Option[a]Description
DescriptionA meaningful description of the unit. This text is displayed for example in the output of the systemctl status command.
Documentation Provides a list of URIs referencing documentation for the unit.
After[b]Defines the order in which units are started. The unit starts only after the units specified in After are active. Unlike Requires, After does not explicitly activate the specified units. The Before option has the opposite functionality to After.
RequiresConfigures dependencies on other units. The units listed in Requires are activated together with the unit. If any of the required units fail to start, the unit is not activated.
WantsConfigures weaker dependencies than Requires. If any of the listed units does not start successfully, it has no impact on the unit activation. This is the recommended way to establish custom unit dependencies.
Conflicts Configures negative dependencies, an opposite to Requires.
[a] For a complete list of options configurable in the [Unit] section, see the systemd.unit(5) manual page.
[b] In most cases, it is sufficient to set only the ordering dependencies with After and Before unit file options. If you also set a requirement dependency with Wants (recommended) or Requires, the ordering dependency still needs to be specified. That is because ordering and requirement dependencies work independently from each other.

Table 9.10. Important [Service] Section Options

Option[a]Description
Type Configures the unit process startup type that affects the functionality of ExecStart and related options. One of:
  • simple – The default value. The process started with ExecStart is the main process of the service.
  • forking – The process started with ExecStart spawns a child process that becomes the main process of the service. The parent process exits when the startup is complete.
  • oneshot – This type is similar to simple, but the process exits before starting consequent units.
  • dbus – This type is similar to simple, but consequent units are started only after the main process gains a D-Bus name.
  • notify – This type is similar to simple, but consequent units are started only after a notification message is sent via the sd_notify() function.
  • idle – similar to simple, the actual execution of the service binary is delayed until all jobs are finished, which avoids mixing the status output with shell output of services.
ExecStartSpecifies commands or scripts to be executed when the unit is started. ExecStartPre and ExecStartPost specify custom commands to be executed before and after ExecStart. Type=oneshot enables specifying multiple custom commands that are then executed sequentially.
ExecStopSpecifies commands or scripts to be executed when the unit is stopped.
ExecReloadSpecifies commands or scripts to be executed when the unit is reloaded.
RestartWith this option enabled, the service is restarted after its process exits, with the exception of a clean stop by the systemctl command.
RemainAfterExitIf set to True, the service is considered active even when all its processes exited. Default value is False. This option is especially useful if Type=oneshot is configured.
[a] For a complete list of options configurable in the [Service] section, see the systemd.service(5) manual page.

Table 9.11. Important [Install] Section Options

Option[a]Description
AliasProvides a space-separated list of additional names for the unit. Most systemctl commands, excluding systemctl enable, can use aliases instead of the actual unit name.
RequiredByA list of units that depend on the unit. When this unit is enabled, the units listed in RequiredBy gain a Require dependency on the unit.
WantedByA list of units that weakly depend on the unit. When this unit is enabled, the units listed in WantedBy gain a Want dependency on the unit.
AlsoSpecifies a list of units to be installed or uninstalled along with the unit.
DefaultInstanceLimited to instantiated units, this option specifies the default instance for which the unit is enabled. See Section 9.6.5, “Working with Instantiated Units”
[a] For a complete list of options configurable in the [Install] section, see the systemd.unit(5) manual page.
A whole range of options that can be used to fine tune the unit configuration, Example 9.17, “postfix.service Unit File” shows an example of a service unit installed on the system. Moreover, unit file options can be defined in a way that enables dynamic creation of units as described in Section 9.6.5, “Working with Instantiated Units”.

Example 9.17. postfix.service Unit File

What follows is the content of the /usr/lib/systemd/system/postifix.service unit file as currently provided by the postfix package:
[Unit]
Description=Postfix Mail Transport Agent
After=syslog.target network.target
Conflicts=sendmail.service exim.service

[Service]
Type=forking
PIDFile=/var/spool/postfix/pid/master.pid
EnvironmentFile=-/etc/sysconfig/network
ExecStartPre=-/usr/libexec/postfix/aliasesdb
ExecStartPre=-/usr/libexec/postfix/chroot-update
ExecStart=/usr/sbin/postfix start
ExecReload=/usr/sbin/postfix reload
ExecStop=/usr/sbin/postfix stop

[Install]
WantedBy=multi-user.target
The [Unit] section describes the service, specifies the ordering dependencies, as well as conflicting units. In [Service], a sequence of custom scripts is specified to be executed during unit activation, on stop, and on reload. EnvironmentFile points to the location where environment variables for the service are defined, PIDFile specifies a stable PID for the main process of the service. Finally, the [Install] section lists units that depend on the service.

9.6.2. Creating Custom Unit Files

There are several use cases for creating unit files from scratch: you could run a custom daemon, create a second instance of some existing service (as in Example 9.19, “Creating a second instance of the sshd service”), or import a SysV init script (more in Section 9.6.3, “Converting SysV Init Scripts to Unit Files”). On the other hand, if you intend just to modify or extend the behavior of an existing unit, use the instructions from Section 9.6.4, “Modifying Existing Unit Files”. The following procedure describes the general process of creating a custom service:
  1. Prepare the executable file with the custom service. This can be a custom-created script, or an executable delivered by a software provider. If required, prepare a PID file to hold a constant PID for the main process of the custom service. It is also possible to include environment files to store shell variables for the service. Make sure the source script is executable (by executing the chmod a+x) and is not interactive.
  2. Create a unit file in the /etc/systemd/system/ directory and make sure it has correct file permissions. Execute as root:
    touch /etc/systemd/system/name.service
    chmod 664 /etc/systemd/system/name.service
    Replace name with a name of the service to be created. Note that file does not need to be executable.
  3. Open the name.service file created in the previous step, and add the service configuration options. There is a variety of options that can be used depending on the type of service you wish to create, see Section 9.6.1, “Understanding the Unit File Structure”. The following is an example unit configuration for a network-related service:
    [Unit]
    Description=service_description
    After=network.target
    
    [Service]
    ExecStart=path_to_executable
    Type=forking
    PIDFile=path_to_pidfile
    
    [Install]
    WantedBy=default.target
    Where:
    • service_description is an informative description that is displayed in journal log files and in the output of the systemctl status command.
    • the After setting ensures that the service is started only after the network is running. Add a space-separated list of other relevant services or targets.
    • path_to_executable stands for the path to the actual service executable.
    • Type=forking is used for daemons that make the fork system call. The main process of the service is created with the PID specified in path_to_pidfile. Find other startup types in Table 9.10, “Important [Service] Section Options”.
    • WantedBy states the target or targets that the service should be started under. Think of these targets as of a replacement of the older concept of runlevels, see Section 9.3, “Working with systemd Targets” for details.
  4. Notify systemd that a new name.service file exists by executing the following command as root:
    systemctl daemon-reload
    systemctl start name.service

    Warning

    Always run the systemctl daemon-reload command after creating new unit files or modifying existing unit files. Otherwise, the systemctl start or systemctl enable commands could fail due to a mismatch between states of systemd and actual service unit files on disk.
    The name.service unit can now be managed as any other system service with commands described in Section 9.2, “Managing System Services”.

Example 9.18. Creating the emacs.service File

When using the Emacs text editor, it is often faster and more convenient to have it running in the background instead of starting a new instance of the program whenever editing a file. The following steps show how to create a unit file for Emacs, so that it can be handled like a service.
  1. Create a unit file in the /etc/systemd/system/ directory and make sure it has the correct file permissions. Execute as root:
    ~]# touch /etc/systemd/system/emacs.service
    ~]# chmod 664 /etc/systemd/system/emacs.service
  2. Add the following content to the file:
    [Unit]
    Description=Emacs: the extensible, self-documenting text editor
               
    [Service]
    Type=forking
    ExecStart=/usr/bin/emacs --daemon
    ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)"
    Environment=SSH_AUTH_SOCK=%t/keyring/ssh
    Restart=always
               
    [Install]
    WantedBy=default.target
    With the above configuration, the /usr/bin/emacs executable is started in daemon mode on service start. The SSH_AUTH_SOCK environment variable is set using the "%t" unit specifier that stands for the runtime directory. The service also restarts the emacs process if it exits unexpectedly.
  3. Execute the following commands to reload the configuration and start the custom service:
    ~]# systemctl daemon-reload
    ~]# systemctl start emacs.service
As the editor is now registered as a systemd service, you can use all standard systemctl commands. For example, run systemctl status emacs to display the editor's status or systemctl enable emacs to make the editor start automatically on system boot.

Example 9.19. Creating a second instance of the sshd service

System Administrators often need to configure and run multiple instances of a service. This is done by creating copies of the original service configuration files and modifying certain parameters to avoid conflicts with the primary instance of the service. The following procedure shows how to create a second instance of the sshd service:
  1. Create a copy of the sshd_config file that will be used by the second daemon:
    ~]# cp /etc/ssh/sshd{,-second}_config
  2. Edit the sshd-second_config file created in the previous step to assign a different port number and PID file to the second daemon:
    Port 22220
    PidFile /var/run/sshd-second.pid
    See the sshd_config(5) manual page for more information on Port and PidFile options. Make sure the port you choose is not in use by any other service. The PID file does not have to exist before running the service, it is generated automatically on service start.
  3. Create a copy of the systemd unit file for the sshd service:
    ~]# cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service
  4. Alter the sshd-second.service created in the previous step as follows:
    1. Modify the Description option:
      Description=OpenSSH server second instance daemon
    2. Add sshd.service to services specified in the After option, so that the second instance starts only after the first one has already started:
      After=syslog.target network.target auditd.service sshd.service
    3. The first instance of sshd includes key generation, therefore remove the ExecStartPre=/usr/sbin/sshd-keygen line.
    4. Add the -f /etc/ssh/sshd-second_config parameter to the sshd command, so that the alternative configuration file is used:
      ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
    5. After the above modifications, the sshd-second.service should look as follows:
      [Unit]
      Description=OpenSSH server second instance daemon
      After=syslog.target network.target auditd.service sshd.service
      
      [Service]
      EnvironmentFile=/etc/sysconfig/sshd
      ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
      ExecReload=/bin/kill -HUP $MAINPID
      KillMode=process
      Restart=on-failure
      RestartSec=42s
      
      [Install]
      WantedBy=multi-user.target
  5. If using SELinux, add the port for the second instance of sshd to SSH ports, otherwise the second instance of sshd will be rejected to bind to the port:
    ~]# semanage port -a -t ssh_port_t -p tcp 22220
  6. Enable sshd-second.service, so that it starts automatically upon boot:
    ~]# systemctl enable sshd-second.service
    Verify if the sshd-second.service is running by using the systemctl status command. Also, verify if the port is enabled correctly by connecting to the service:
    ~]$ ssh -p 22220 user@server
    If the firewall is in use, please make sure that it is configured appropriately in order to allow connections to the second instance of sshd.
To learn how to properly choose a target for ordering and dependencies of your custom unit files, see the following articles::
Additional information with some real-world examples of cases triggered by the ordering and dependencies in a unit file is available in the following article: Is there any useful information about writing unit files?
If you want to set limits for services started by systemd, see the Red Hat Knowledgebase article How to set limits for services in RHEL 7 and systemd. These limits need to be set in the service's unit file. Note that systemd ignores limits set in the /etc/security/limits.conf and /etc/security/limits.d/*.conf configuration files. The limits defined in these files are set by PAM when starting a login session, but daemons started by systemd do not use PAM login sessions.

9.6.3. Converting SysV Init Scripts to Unit Files

Before taking time to convert a SysV init script to a unit file, make sure that the conversion was not already done elsewhere. All core services installed on Red Hat Enterprise Linux 7 come with default unit files, and the same applies for many third-party software packages.
Converting an init script to a unit file requires analyzing the script and extracting the necessary information from it. Based on this data you can create a unit file as described in Section 9.6.2, “Creating Custom Unit Files”. As init scripts can vary greatly depending on the type of the service, you might need to employ more configuration options for translation than outlined in this chapter. Note that some levels of customization that were available with init scripts are no longer supported by systemd units, see Section 9.1.2, “Compatibility Changes”.
The majority of information needed for conversion is provided in the script's header. The following example shows the opening section of the init script used to start the postfix service on Red Hat Enterprise Linux 6:
#!/bin/bash
#
# postfix      Postfix Mail Transfer Agent
#
# chkconfig: 2345 80 30
# description: Postfix is a Mail Transport Agent, which is the program \
#              that moves mail from one machine to another.
# processname: master
# pidfile: /var/spool/postfix/pid/master.pid
# config: /etc/postfix/main.cf
# config: /etc/postfix/master.cf

### BEGIN INIT INFO
# Provides: postfix MTA
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop postfix
# Description: Postfix is a Mail Transport Agent, which is the program that 
#              moves mail from one machine to another.
### END INIT INFO
In the above example, only lines starting with # chkconfig and # description are mandatory, so you might not find the rest in different init files. The text enclosed between the ### BEGIN INIT INFO and ### END INIT INFO lines is called Linux Standard Base (LSB) header. If specified, LSB headers contain directives defining the service description, dependencies, and default runlevels. What follows is an overview of analytic tasks aiming to collect the data needed for a new unit file. The postfix init script is used as an example, see the resulting postfix unit file in Example 9.17, “postfix.service Unit File”.

Finding the Service Description

Find descriptive information about the script on the line starting with #description. Use this description together with the service name in the Description option in the [Unit] section of the unit file. The LSB header might contain similar data on the #Short-Description and #Description lines.

Finding Service Dependencies

The LSB header might contain several directives that form dependencies between services. Most of them are translatable to systemd unit options, see Table 9.12, “Dependency Options from the LSB Header”

Table 9.12. Dependency Options from the LSB Header

LSB OptionDescriptionUnit File Equivalent
ProvidesSpecifies the boot facility name of the service, that can be referenced in other init scripts (with the "$" prefix). This is no longer needed as unit files refer to other units by their file names.
Required-StartContains boot facility names of required services. This is translated as an ordering dependency, boot facility names are replaced with unit file names of corresponding services or targets they belong to. For example, in case of postfix, the Required-Start dependency on $network was translated to the After dependency on network.target.After, Before
Should-StartConstitutes weaker dependencies than Required-Start. Failed Should-Start dependencies do not affect the service startup.After, Before
Required-Stop, Should-StopConstitute negative dependencies.Conflicts

Finding Default Targets of the Service

The line starting with #chkconfig contains three numerical values. The most important is the first number that represents the default runlevels in which the service is started. Use Table 9.6, “Comparison of SysV Runlevels with systemd Targets” to map these runlevels to equivalent systemd targets. Then list these targets in the WantedBy option in the [Install] section of the unit file. For example, postfix was previously started in runlevels 2, 3, 4, and 5, which translates to multi-user.target and graphical.target on Red Hat Enterprise Linux 7. Note that the graphical.target depends on multiuser.target, therefore it is not necessary to specify both, as in Example 9.17, “postfix.service Unit File”. You might find information on default and forbidden runlevels also at #Default-Start and #Default-Stop lines in the LSB header.
The other two values specified on the #chkconfig line represent startup and shutdown priorities of the init script. These values are interpreted by systemd if it loads the init script, but there is no unit file equivalent.

Finding Files Used by the Service

Init scripts require loading a function library from a dedicated directory and allow importing configuration, environment, and PID files. Environment variables are specified on the line starting with #config in the init script header, which translates to the EnvironmentFile unit file option. The PID file specified on the #pidfile init script line is imported to the unit file with the PIDFile option.
The key information that is not included in the init script header is the path to the service executable, and potentially some other files required by the service. In previous versions of Red Hat Enterprise Linux, init scripts used a Bash case statement to define the behavior of the service on default actions, such as start, stop, or restart, as well as custom-defined actions. The following excerpt from the postfix init script shows the block of code to be executed at service start.
conf_check() {
    [ -x /usr/sbin/postfix ] || exit 5
    [ -d /etc/postfix ] || exit 6
    [ -d /var/spool/postfix ] || exit 5
}

make_aliasesdb() {
	if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ]
	then
		# /etc/aliases.db might be used by other MTA, make sure nothing
		# has touched it since our last newaliases call
		[ /etc/aliases -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return
		/usr/bin/newaliases
		touch -r /etc/aliases.db "$ALIASESDB_STAMP"
	else
		/usr/bin/newaliases
	fi
}

start() {
	[ "$EUID" != "0" ] && exit 4
	# Check that networking is up.
	[ ${NETWORKING} = "no" ] && exit 1
	conf_check
	# Start daemons.
	echo -n $"Starting postfix: "
	make_aliasesdb >/dev/null 2>&1
	[ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE
	/usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start"
	RETVAL=$?
	[ $RETVAL -eq 0 ] && touch $lockfile
        echo
	return $RETVAL
}
The extensibility of the init script allowed specifying two custom functions, conf_check() and make_aliasesdb(), that are called from the start() function block. On closer look, several external files and directories are mentioned in the above code: the main service executable /usr/sbin/postfix, the /etc/postfix/ and /var/spool/postfix/ configuration directories, as well as the /usr/sbin/postconf/ directory.
Systemd supports only the predefined actions, but enables executing custom executables with ExecStart, ExecStartPre, ExecStartPost, ExecStop, and ExecReload options. In case of postfix on Red Hat Enterprise Linux 7, the /usr/sbin/postfix together with supporting scripts are executed on service start. Consult the postfix unit file at Example 9.17, “postfix.service Unit File”.
Converting complex init scripts requires understanding the purpose of every statement in the script. Some of the statements are specific to the operating system version, therefore you do not need to translate them. On the other hand, some adjustments might be needed in the new environment, both in unit file as well as in the service executable and supporting files.

9.6.4. Modifying Existing Unit Files

Services installed on the system come with default unit files that are stored in the /usr/lib/systemd/system/ directory. System Administrators should not modify these files directly, therefore any customization must be confined to configuration files in the /etc/systemd/system/ directory. Depending on the extent of the required changes, pick one of the following approaches:
  • Create a directory for supplementary configuration files at /etc/systemd/system/unit.d/. This method is recommended for most use cases. It enables extending the default configuration with additional functionality, while still referring to the original unit file. Changes to the default unit introduced with a package upgrade are therefore applied automatically. See the section called “Extending the Default Unit Configuration” for more information.
  • Create a copy of the original unit file /usr/lib/systemd/system/ in /etc/systemd/system/ and make changes there. The copy overrides the original file, therefore changes introduced with the package update are not applied. This method is useful for making significant unit changes that should persist regardless of package updates. See the section called “Overriding the Default Unit Configuration” for details.
In order to return to the default configuration of the unit, just delete custom-created configuration files in /etc/systemd/system/. To apply changes to unit files without rebooting the system, execute:
systemctl daemon-reload
The daemon-reload option reloads all unit files and recreates the entire dependency tree, which is needed to immediately apply any change to a unit file. As an alternative, you can achieve the same result with the following command:
init q
Also, if the modified unit file belongs to a running service, this service must be restarted to accept new settings:
systemctl restart name.service

Important

To modify properties, such as dependencies or timeouts, of a service that is handled by a SysV initscript, do not modify the initscript itself. Instead, create a systemd drop-in configuration file for the service as described in the section called “Extending the Default Unit Configuration” and the section called “Overriding the Default Unit Configuration”. Then manage this service in the same way as a normal systemd service.
For example, to extend the configuration of the network service, do not modify the /etc/rc.d/init.d/network initscript file. Instead, create new directory /etc/systemd/system/network.service.d/ and a systemd drop-in file /etc/systemd/system/network.service.d/my_config.conf. Then, put the modified values into the drop-in file. Note: systemd knows the network service as network.service, which is why the created directory must be called network.service.d

Extending the Default Unit Configuration

To extend the default unit file with additional configuration options, first create a configuration directory in /etc/systemd/system/. If extending a service unit, execute the following command as root:
mkdir /etc/systemd/system/name.service.d/
Replace name with the name of the service you want to extend. The above syntax applies to all unit types.
Create a configuration file in the directory made in the previous step. Note that the file name must end with the .conf suffix. Type:
touch /etc/systemd/system/name.service.d/config_name.conf
Replace config_name with the name of the configuration file. This file adheres to the normal unit file structure, therefore all directives must be specified under appropriate sections, see Section 9.6.1, “Understanding the Unit File Structure”.
For example, to add a custom dependency, create a configuration file with the following content:
[Unit]
Requires=new_dependency
After=new_dependency
Where new_dependency stands for the unit to be marked as a dependency. Another example is a configuration file that restarts the service after its main process exited, with a delay of 30 seconds:
[Service]
Restart=always
RestartSec=30
It is recommended to create small configuration files focused only on one task. Such files can be easily moved or linked to configuration directories of other services.
To apply changes made to the unit, execute as root:
systemctl daemon-reload
systemctl restart name.service

Example 9.20. Extending the httpd.service Configuration

To modify the httpd.service unit so that a custom shell script is automatically executed when starting the Apache service, perform the following steps. First, create a directory and a custom configuration file:
~]# mkdir /etc/systemd/system/httpd.service.d/
~]# touch /etc/systemd/system/httpd.service.d/custom_script.conf
Provided that the script you want to start automatically with Apache is located at /usr/local/bin/custom.sh, insert the following text to the custom_script.conf file:
[Service]
ExecStartPost=/usr/local/bin/custom.sh
To apply the unit changes, execute:
~]# systemctl daemon-reload
~]# systemctl restart httpd.service

Note

The configuration files from configuration directories in /etc/systemd/system/ take precedence over unit files in /usr/lib/systemd/system/. Therefore, if the configuration files contain an option that can be specified only once, such as Description or ExecStart, the default value of this option is overridden. Note that in the output of the systemd-delta command, described in the section called “Monitoring Overriden Units”, such units are always marked as [EXTENDED], even though in sum, certain options are actually overridden.

Overriding the Default Unit Configuration

To make changes that will persist after updating the package that provides the unit file, first copy the file to the /etc/systemd/system/ directory. To do so, execute the following command as root:
cp /usr/lib/systemd/system/name.service /etc/systemd/system/name.service
Where name stands for the name of the service unit you wish to modify. The above syntax applies to all unit types.
Open the copied file with a text editor, and make the desired changes. To apply the unit changes, execute as root:
systemctl daemon-reload
systemctl restart name.service

Example 9.21. Changing the timeout limit

You can specify a timeout value per service to prevent a malfunctioning service from freezing the system. Otherwise, timeout is set by default to 90 seconds for normal services and to 300 seconds for SysV-compatible services.
For example, to extend timeout limit for the httpd service:
  1. Copy the httpd unit file to the /etc/systemd/system/ directory:
    cp /usr/lib/systemd/system/httpd.service /etc/systemd/system/httpd.service
  2. Open file /etc/systemd/system/httpd.service and specify the TimeoutStartUSec value in the [Service] section:
    ...
    [Service]
    ...
    PrivateTmp=true
    TimeoutStartSec=10
    
    [Install]
    WantedBy=multi-user.target
    ...
  3. Reload the systemd daemon:
    systemctl daemon-reload
  4. Optional. Verify the new timeout value:
    systemctl show httpd -p TimeoutStartUSec

Note

To change the timeout limit globally, input the DefaultTimeoutStartSec in the /etc/systemd/system.conf file. See Section 9.1, “Introduction to systemd”.

Monitoring Overriden Units

To display an overview of overridden or modified unit files, use the following command:
systemd-delta
For example, the output of the above command can look as follows:
[EQUIVALENT] /etc/systemd/system/default.target → /usr/lib/systemd/system/default.target
[OVERRIDDEN] /etc/systemd/system/autofs.service → /usr/lib/systemd/system/autofs.service

--- /usr/lib/systemd/system/autofs.service      2014-10-16 21:30:39.000000000 -0400
+++ /etc/systemd/system/autofs.service  2014-11-21 10:00:58.513568275 -0500
@@ -8,7 +8,8 @@
 EnvironmentFile=-/etc/sysconfig/autofs
 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid
 ExecReload=/usr/bin/kill -HUP $MAINPID
-TimeoutSec=180
+TimeoutSec=240
+Restart=Always
 
 [Install]
 WantedBy=multi-user.target

[MASKED]     /etc/systemd/system/cups.service → /usr/lib/systemd/system/cups.service
[EXTENDED]   /usr/lib/systemd/system/sssd.service → /etc/systemd/system/sssd.service.d/journal.conf

4 overridden configuration files found.
Table 9.13, “systemd-delta Difference Types” lists override types that can appear in the output of systemd-delta. Note that if a file is overridden, systemd-delta by default displays a summary of changes similar to the output of the diff command.

Table 9.13. systemd-delta Difference Types

TypeDescription
[MASKED]
Masked unit files, see Section 9.2.7, “Disabling a Service” for description of unit masking.
[EQUIVALENT]
Unmodified copies that override the original files but do not differ in content, typically symbolic links.
[REDIRECTED]
Files that are redirected to another file.
[OVERRIDEN]
Overridden and changed files.
[EXTENDED]
Files that are extended with .conf files in the /etc/systemd/system/unit.d/ directory.
[UNCHANGED]
Unmodified files are displayed only when the --type=unchanged option is used.
It is good practice to run systemd-delta after system update to check if there are any updates to the default units that are currently overridden by custom configuration. It is also possible to limit the output only to a certain difference type. For example, to view just the overridden units, execute:
systemd-delta --type=overridden

9.6.5. Working with Instantiated Units

It is possible to instantiate multiple units from a single template configuration file at runtime. The "@" character is used to mark the template and to associate units with it. Instantiated units can be started from another unit file (using Requires or Wants options), or with the systemctl start command. Instantiated service units are named the following way:
template_name@instance_name.service
Where template_name stands for the name of the template configuration file. Replace instance_name with the name for the unit instance. Several instances can point to the same template file with configuration options common for all instances of the unit. Template unit name has the form of:
unit_name@.service
For example, the following Wants setting in a unit file:
Wants=getty@ttyA.service,getty@ttyB.service
first makes systemd search for given service units. If no such units are found, the part between "@" and the type suffix is ignored and systemd searches for the getty@.service file, reads the configuration from it, and starts the services.
Wildcard characters, called unit specifiers, can be used in any unit configuration file. Unit specifiers substitute certain unit parameters and are interpreted at runtime. Table 9.14, “Important Unit Specifiers” lists unit specifiers that are particularly useful for template units.

Table 9.14. Important Unit Specifiers

Unit SpecifierMeaningDescription
%nFull unit nameStands for the full unit name including the type suffix. %N has the same meaning but also replaces the forbidden characters with ASCII codes.
%pPrefix nameStands for a unit name with type suffix removed. For instantiated units %p stands for the part of the unit name before the "@" character.
%iInstance nameIs the part of the instantiated unit name between the "@" character and the type suffix. %I has the same meaning but also replaces the forbidden characters for ASCII codes.
%HHost nameStands for the hostname of the running system at the point in time the unit configuration is loaded.
%tRuntime directoryRepresents the runtime directory, which is either /run for the root user, or the value of the XDG_RUNTIME_DIR variable for unprivileged users.
For a complete list of unit specifiers, see the systemd.unit(5) manual page.
For example, the getty@.service template contains the following directives:
[Unit]
Description=Getty on %I
...
[Service]
ExecStart=-/sbin/agetty --noclear %I $TERM
...
When the getty@ttyA.service and getty@ttyB.service are instantiated form the above template, Description= is resolved as Getty on ttyA and Getty on ttyB.

9.7. Additional Resources

For more information on systemd and its usage on Red Hat Enterprise Linux 7, see the resources listed below.

Installed Documentation

  • systemctl(1) — The manual page for the systemctl command line utility provides a complete list of supported options and commands.
  • systemd(1) — The manual page for the systemd system and service manager provides more information about its concepts and documents available command line options and environment variables, supported configuration files and directories, recognized signals, and available kernel options.
  • systemd-delta(1) — The manual page for the systemd-delta utility that allows to find extended and overridden configuration files.
  • systemd.unit(5) — The manual page named systemd.unit provides detailed information about systemd unit files and documents all available configuration options.
  • systemd.service(5) — The manual page named systemd.service documents the format of service unit files.
  • systemd.target(5) — The manual page named systemd.target documents the format of target unit files.
  • systemd.kill(5) — The manual page named systemd.kill documents the configuration of the process killing procedure.

Online Documentation

  • Red Hat Enterprise Linux 7 Networking Guide — The Networking Guide for Red Hat Enterprise Linux 7 documents relevant information regarding the configuration and administration of network interfaces, networks, and network services in this system. It provides an introduction to the hostnamectl utility, explains how to use it to view and set host names on the command line, both locally and remotely, and provides important information about the selection of host names and domain names.
  • Red Hat Enterprise Linux 7 Desktop Migration and Administration Guide — The Desktop Migration and Administration Guide for Red Hat Enterprise Linux 7 documents the migration planning, deployment, configuration, and administration of the GNOME 3 desktop on this system. It introduces the logind service, enumerates its most significant features, and explains how to use the loginctl utility to list active sessions and enable multi-seat support.
  • Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide — The SELinux User's and Administrator's Guide for Red Hat Enterprise Linux 7 describes the basic principles of SELinux and documents in detail how to configure and use SELinux with various services such as the Apache HTTP Server, Postfix, PostgreSQL, or OpenShift. It explains how to configure SELinux access permissions for system services managed by systemd.
  • Red Hat Enterprise Linux 7 Installation Guide — The Installation Guide for Red Hat Enterprise Linux 7 documents how to install the system on AMD64 and Intel 64 systems, 64-bit IBM Power Systems servers, and IBM System z. It also covers advanced installation methods such as Kickstart installations, PXE installations, and installations over the VNC protocol. In addition, it describes common post-installation tasks and explains how to troubleshoot installation problems, including detailed instructions on how to boot into rescue mode or recover the root password.
  • Red Hat Enterprise Linux 7 Security Guide — The Security Guide for Red Hat Enterprise Linux 7 assists users and administrators in learning the processes and practices of securing their workstations and servers against local and remote intrusion, exploitation, and malicious activity. It also explains how to secure critical system services.
  • systemd Home Page — The project home page provides more information about systemd.

See Also

  • Chapter 1, System Locale and Keyboard Configuration documents how to manage the system locale and keyboard layouts. It explains how to use the localectl utility to view the current locale, list available locales, and set the system locale on the command line, as well as to view the current keyboard layout, list available keymaps, and enable a particular keyboard layout on the command line.
  • Chapter 2, Configuring the Date and Time documents how to manage the system date and time. It explains the difference between a real-time clock and system clock and describes how to use the timedatectl utility to display the current settings of the system clock, configure the date and time, change the time zone, and synchronize the system clock with a remote server.
  • Chapter 5, Gaining Privileges documents how to gain administrative privileges by using the su and sudo commands.
  • Chapter 11, OpenSSH describes how to configure an SSH server and how to use the ssh, scp, and sftp client utilities to access it.
  • Chapter 21, Viewing and Managing Log Files provides an introduction to journald. It describes the journal, introduces the journald service, and documents how to use the journalctl utility to view log entries, enter live view mode, and filter log entries. In addition, this chapter describes how to give non-root users access to system logs and enable persistent storage for log files.

Chapter 10. Configuring a System for Accessibility

Accessibility in Red Hat Enterprise Linux 7 is ensured by the Orca screen reader, which is included in the default installation of the operating system. This chapter explains how a system administrator can configure a system to support users with a visual impairment.
Orca reads information from the screen and communicates it to the user using:
  • a speech synthesizer, which provides a speech output
  • a braille display, which provides a tactile output
For more information on Orca settings, see its help page.
In order that Orca's communication outputs function properly, the system administrator needs to:

10.1. Configuring the brltty Service

The Braille display uses the brltty service to provide tactile output for visually impaired users.

Enable the brltty Service

The braille display cannot work unless brltty is running. By default, brltty is disabled. Enable brltty to be started on boot:
~]# systemctl enable brltty.service

Authorize Users to Use the Braille Display

To set the users who are authorized to use the braille display, choose one of the following procedures, which have an equal effect. The procedure using the /etc/brltty.conf file is suitable even for the file systems where users or groups cannot be assigned to a file. The procedure using the /etc/brlapi.key file is suitable only for the file systems where users or groups can be assigned to a file.

Procedure 10.1. Setting Access to Braille Display by Using /etc/brltty.conf

  1. Open the /etc/brltty.conf file, and find the section called Application Programming Interface Parameters.
  2. Specify the users.
    1. To specify one or more individual users, list the users on the following line:
      api-parameters Auth=user:user_1, user_2, ... 		# Allow some local user
    2. To specify a user group, enter its name on the following line:
      api-parameters Auth=group:group		# Allow some local group

Procedure 10.2. Setting Access to Braille Display by Using /etc/brlapi.key

  1. Create the /etc/brlapi.key file.
    ~]# mcookie > /etc/brlapi.key
  2. Change ownership of the /etc/brlapi.key to particular user or group.
    1. To specify an individual user:
      ~]# chown user_1 /etc/brlapi.key
    2. To specify a group:
      ~]# chown group_1 /etc/brlapi.key 
  3. Adjust the content of /etc/brltty.conf to include this:
    api-parameters Auth=keyfile:/etc/brlapi.key

Set the Braille Driver

The braille-driver directive in /etc/brltty.conf specifies a two-letter driver identification code of the driver for the braille display.

Procedure 10.3. Setting the Braille Driver

  • Decide whether you want to use the autodetection for finding the appropriate braille driver.
    1. If you want to use autodetection, leave braille driver specified to auto, which is the default option.
      braille-driver	auto	 # autodetect

      Warning

      Autodetection tries all drivers. Therefore, it might take a long time or even fail. For this reason, setting up a particular braille driver is recommended.
    2. If you do not want to use the autodetection, specify the identification code of the required braille driver in the braille-driver directive.
      Choose the identification code of required braille driver from the list provided in /etc/brltty.conf, for example:
      braille-driver	xw	 # XWindow
      You can also set multiple drivers, separated by commas, and autodetection is then performed among them.

Set the Braille Device

The braille-device directive in /etc/brltty.conf specifies the device to which the braille display is connected. The following device types are supported (see Table 10.1, “Braille Device Types and the Corresponding Syntax”):

Table 10.1. Braille Device Types and the Corresponding Syntax

Braille Device TypeSyntax of the Type
serial deviceserial:path [a]
USB device[serial-number] [b]
Bluetooth devicebluetooth:address
[a] Relative paths are at /dev.
[b] The brackets ([]) here indicate optionality.
Examples of settings for particular devices:
braille-device	serial:ttyS0	                # First serial device
braille-device	usb:	                        # First USB device matching braille driver
braille-device	usb:nnnnn	                # Specific USB device by serial number
braille-device	bluetooth:xx:xx:xx:xx:xx:xx	# Specific Bluetooth device by address
You can also set multiple devices, separated by commas, and each of them will be probed in turn.

Warning

If the device is connected by a serial-to-USB adapter, setting braille-device to usb: does not work. In this case, identify the virtual serial device that the kernel has created for the adapter. The virtual serial device can look like this:
serial:ttyUSB0
You can find the actual device name in the kernel messages on the device plug with the following command:
~]# dmesg | fgrep ttyUSB0

Set Specific Parameters for Particular Braille Displays

If you need to set specific parameters for particular braille displays, use the braille-parameters directive in /etc/brltty.conf. The braille-parameters directive passes non-generic parameters through to the braille driver. Choose the required parameters from the list in /etc/brltty.conf.

Set the Text Table

The text-table directive in /etc/brltty.conf specifies which text table is used to encode the symbols. Relative paths to text tables are in the /etc/brltty/Text/ directory.

Procedure 10.4. Setting the Text Table

  1. Decide whether you want to use the autoselection for finding the appropriate text table.
    1. If you want to use the autoselection, leave text-table specified to auto, which is the default option.
      text-table	auto	 # locale-based autoselection
      This ensures that local-based autoselection with fallback to en-nabcc is performed.
    2. If you do not want to use the autoselection, choose the required text-table from the list in /etc/brltty.conf.
      For example, to use the text table for American English:
      text-table	en_US	 # English (United States)

Set the Contraction Table

The contraction-table directive in /etc/brltty.conf specifies which table is used to encode the abbreviations. Relative paths to particular contraction tables are in the /etc/brltty/Contraction/ directory.
Choose the required contraction-table from the list in /etc/brltty.conf.
For example, to use the contraction table for American English, grade 2:
contraction-table	en-us-g2	 # English (US, grade 2)

Warning

If not specified, no contraction table is used.

10.2. Switch On Always Show Universal Access Menu

To switch on the Orca screen reader, press the Super+Alt+S key combination. As a result, the Universal Access Menu icon is displayed on the top bar.

Warning

The icon disappears in case that the user switches off all of the provided options from the Universal Access Menu. Missing icon can cause difficulties to users with a visual impairment. System administrators can prevent the inaccessibility of the icon by switching on the Always Show Universal Access Menu. When the Always Show Universal Access Menu is switched on, the icon is displayed on the top bar even in the situation when all options from this menu are switched off.

Procedure 10.5. Switching On Always Show Universal Access Menu

  1. Open the Gnome settings menu, and click Universal Access.
  2. Switch on Always Show Universal Access Menu.
  3. Optional: Verify that the Universal Access Menu icon is displayed on the top bar even if all options from this menu are switched off.

10.3. Enabling the Festival Speech Synthesis System

By default, Orca uses the eSpeak speech synthesizer, but it also supports the Festival Speech Synthesis System. Both eSpeak and Festival Speech Synthesis System (Festival) synthesize voice differently. Some users might prefer Festival to the default eSpeak synthesizer. To enable Festival, follow these steps:

Procedure 10.6. Installing Festival and Making it Running on Boot

  1. Install Festival:
    ~]# yum install festival festival-freebsoft-utils
  2. Make Festival running on boot:
    1. Create a new systemd unit file:
      Create a file in the /etc/systemd/system/ directory and make it executable.
      ~]# touch /etc/systemd/system/festival.service
      ~]# chmod 664 /etc/systemd/system/festival.service
    2. Ensure that the script in the /usr/bin/festival_server file is used to run Festival. Add the following content to the /etc/systemd/system/festival.service file:
      [Unit]
      Description=Festival speech synthesis server
      [Service]
      ExecStart=/usr/bin/festival_server
      Type=simple
      
    3. Notify systemd that a new festival.service file exists:
      ~]# systemctl daemon-reload
      ~]# systemctl start festival.service
    4. Enable festival.service:
      ~]# systemctl enable festival.service

Choose a Voice for Festival

Festival provides multiples voices.
To make a voice available, install the relevant package from the following list:
  • festvox-awb-arctic-hts
  • festvox-bdl-arctic-hts
  • festvox-clb-arctic-hts
  • festvox-kal-diphone
  • festvox-ked-diphone
  • festvox-rms-arctic-hts
  • festvox-slt-arctic-hts
  • hispavoces-pal-diphone
  • hispavoces-sfl-diphone
To see detailed information about a particular voice:
~]# yum info package_name
To make the required voice available, install the package with this voice and then reboot:
~]# yum install package_name
~]# reboot

Chapter 11. OpenSSH

SSH (Secure Shell) is a protocol which facilitates secure communications between two systems using a client-server architecture and allows users to log in to server host systems remotely. Unlike other remote communication protocols, such as FTP or Telnet, SSH encrypts the login session, rendering the connection difficult for intruders to collect unencrypted passwords.
The ssh program is designed to replace older, less secure terminal applications used to log in to remote hosts, such as telnet or rsh. A related program called scp replaces older programs designed to copy files between hosts, such as rcp. Because these older applications do not encrypt passwords transmitted between the client and the server, avoid them whenever possible. Using secure methods to log in to remote systems decreases the risks for both the client system and the remote host.
Red Hat Enterprise Linux includes the general OpenSSH package, openssh, as well as the OpenSSH server, openssh-server, and client, openssh-clients, packages. Note, the OpenSSH packages require the OpenSSL package openssl-libs, which installs several important cryptographic libraries, enabling OpenSSH to provide encrypted communications.

11.1. The SSH Protocol

11.1.1. Why Use SSH?

Potential intruders have a variety of tools at their disposal enabling them to disrupt, intercept, and re-route network traffic in an effort to gain access to a system. In general terms, these threats can be categorized as follows:
Interception of communication between two systems
The attacker can be somewhere on the network between the communicating parties, copying any information passed between them. He may intercept and keep the information, or alter the information and send it on to the intended recipient.
This attack is usually performed using a packet sniffer, a rather common network utility that captures each packet flowing through the network, and analyzes its content.
Impersonation of a particular host
Attacker's system is configured to pose as the intended recipient of a transmission. If this strategy works, the user's system remains unaware that it is communicating with the wrong host.
This attack can be performed using a technique known as DNS poisoning, or via so-called IP spoofing. In the first case, the intruder uses a cracked DNS server to point client systems to a maliciously duplicated host. In the second case, the intruder sends falsified network packets that appear to be from a trusted host.
Both techniques intercept potentially sensitive information and, if the interception is made for hostile reasons, the results can be disastrous. If SSH is used for remote shell login and file copying, these security threats can be greatly diminished. This is because the SSH client and server use digital signatures to verify their identity. Additionally, all communication between the client and server systems is encrypted. Attempts to spoof the identity of either side of a communication does not work, since each packet is encrypted using a key known only by the local and remote systems.

11.1.2. Main Features

The SSH protocol provides the following safeguards:
No one can pose as the intended server
After an initial connection, the client can verify that it is connecting to the same server it had connected to previously.
No one can capture the authentication information
The client transmits its authentication information to the server using strong, 128-bit encryption.
No one can intercept the communication
All data sent and received during a session is transferred using 128-bit encryption, making intercepted transmissions extremely difficult to decrypt and read.
Additionally, it also offers the following options:
It provides secure means to use graphical applications over a network
Using a technique called X11 forwarding, the client can forward X11 (X Window System) applications from the server.
It provides a way to secure otherwise insecure protocols
The SSH protocol encrypts everything it sends and receives. Using a technique called port forwarding, an SSH server can become a conduit to securing otherwise insecure protocols, like POP, and increasing overall system and data security.
It can be used to create a secure channel
The OpenSSH server and client can be configured to create a tunnel similar to a virtual private network for traffic between server and client machines.
It supports the Kerberos authentication
OpenSSH servers and clients can be configured to authenticate using the GSSAPI (Generic Security Services Application Program Interface) implementation of the Kerberos network authentication protocol.

11.1.3. Protocol Versions

Two varieties of SSH currently exist: version 1, and newer version 2. The OpenSSH suite under Red Hat Enterprise Linux uses SSH version 2, which has an enhanced key exchange algorithm not vulnerable to the known exploit in version 1. However, for compatibility reasons, the OpenSSH suite does support version 1 connections as well.

Important

To ensure maximum security for your connection, it is recommended that only SSH version 2-compatible servers and clients are used whenever possible.

11.1.4. Event Sequence of an SSH Connection

The following series of events help protect the integrity of SSH communication between two hosts.
  1. A cryptographic handshake is made so that the client can verify that it is communicating with the correct server.
  2. The transport layer of the connection between the client and remote host is encrypted using a symmetric cipher.
  3. The client authenticates itself to the server.
  4. The client interacts with the remote host over the encrypted connection.

11.1.4.1. Transport Layer

The primary role of the transport layer is to facilitate safe and secure communication between the two hosts at the time of authentication and during subsequent communication. The transport layer accomplishes this by handling the encryption and decryption of data, and by providing integrity protection of data packets as they are sent and received. The transport layer also provides compression, speeding the transfer of information.
Once an SSH client contacts a server, key information is exchanged so that the two systems can correctly construct the transport layer. The following steps occur during this exchange:
  • Keys are exchanged
  • The public key encryption algorithm is determined
  • The symmetric encryption algorithm is determined
  • The message authentication algorithm is determined
  • The hash algorithm is determined
During the key exchange, the server identifies itself to the client with a unique host key. If the client has never communicated with this particular server before, the server's host key is unknown to the client and it does not connect. OpenSSH gets around this problem by accepting the server's host key. This is done after the user is notified and has both accepted and verified the new host key. In subsequent connections, the server's host key is checked against the saved version on the client, providing confidence that the client is indeed communicating with the intended server. If, in the future, the host key no longer matches, the user must remove the client's saved version before a connection can occur.

Warning

It is possible for an attacker to masquerade as an SSH server during the initial contact since the local system does not know the difference between the intended server and a false one set up by an attacker. To help prevent this, verify the integrity of a new SSH server by contacting the server administrator before connecting for the first time or in the event of a host key mismatch.
SSH is designed to work with almost any kind of public key algorithm or encoding format. After an initial key exchange creates a hash value used for exchanges and a shared secret value, the two systems immediately begin calculating new keys and algorithms to protect authentication and future data sent over the connection.
After a certain amount of data has been transmitted using a given key and algorithm (the exact amount depends on the SSH implementation), another key exchange occurs, generating another set of hash values and a new shared secret value. Even if an attacker is able to determine the hash and shared secret value, this information is only useful for a limited period of time.

11.1.4.2. Authentication

Once the transport layer has constructed a secure tunnel to pass information between the two systems, the server tells the client the different authentication methods supported, such as using a private key-encoded signature or typing a password. The client then tries to authenticate itself to the server using one of these supported methods.
SSH servers and clients can be configured to allow different types of authentication, which gives each side the optimal amount of control. The server can decide which encryption methods it supports based on its security model, and the client can choose the order of authentication methods to attempt from the available options.

11.1.4.3. Channels

After a successful authentication over the SSH transport layer, multiple channels are opened via a technique called multiplexing[1]. Each of these channels handles communication for different terminal sessions and for forwarded X11 sessions.
Both clients and servers can create a new channel. Each channel is then assigned a different number on each end of the connection. When the client attempts to open a new channel, the clients sends the channel number along with the request. This information is stored by the server and is used to direct communication to that channel. This is done so that different types of sessions do not affect one another and so that when a given session ends, its channel can be closed without disrupting the primary SSH connection.
Channels also support flow-control, which allows them to send and receive data in an orderly fashion. In this way, data is not sent over the channel until the client receives a message that the channel is open.
The client and server negotiate the characteristics of each channel automatically, depending on the type of service the client requests and the way the user is connected to the network. This allows great flexibility in handling different types of remote connections without having to change the basic infrastructure of the protocol.

11.2. Configuring OpenSSH

11.2.1. Configuration Files

There are two different sets of configuration files: those for client programs (that is, ssh, scp, and sftp), and those for the server (the sshd daemon).
System-wide SSH configuration information is stored in the /etc/ssh/ directory as described in Table 11.1, “System-wide configuration files”. User-specific SSH configuration information is stored in ~/.ssh/ within the user's home directory as described in Table 11.2, “User-specific configuration files”.

Table 11.1. System-wide configuration files

FileDescription
/etc/ssh/moduli Contains Diffie-Hellman groups used for the Diffie-Hellman key exchange which is critical for constructing a secure transport layer. When keys are exchanged at the beginning of an SSH session, a shared, secret value is created which cannot be determined by either party alone. This value is then used to provide host authentication.
/etc/ssh/ssh_config The default SSH client configuration file. Note that it is overridden by ~/.ssh/config if it exists.
/etc/ssh/sshd_config The configuration file for the sshd daemon.
/etc/ssh/ssh_host_ecdsa_key The ECDSA private key used by the sshd daemon.
/etc/ssh/ssh_host_ecdsa_key.pub The ECDSA public key used by the sshd daemon.
/etc/ssh/ssh_host_key The RSA private key used by the sshd daemon for version 1 of the SSH protocol.
/etc/ssh/ssh_host_key.pub The RSA public key used by the sshd daemon for version 1 of the SSH protocol.
/etc/ssh/ssh_host_rsa_key The RSA private key used by the sshd daemon for version 2 of the SSH protocol.
/etc/ssh/ssh_host_rsa_key.pub The RSA public key used by the sshd daemon for version 2 of the SSH protocol.
/etc/pam.d/sshd The PAM configuration file for the sshd daemon.
/etc/sysconfig/sshd Configuration file for the sshd service.

Table 11.2. User-specific configuration files

FileDescription
~/.ssh/authorized_keys Holds a list of authorized public keys for servers. When the client connects to a server, the server authenticates the client by checking its signed public key stored within this file.
~/.ssh/id_ecdsa Contains the ECDSA private key of the user.
~/.ssh/id_ecdsa.pub The ECDSA public key of the user.
~/.ssh/id_rsa The RSA private key used by ssh for version 2 of the SSH protocol.
~/.ssh/id_rsa.pub The RSA public key used by ssh for version 2 of the SSH protocol.
~/.ssh/identity The RSA private key used by ssh for version 1 of the SSH protocol.
~/.ssh/identity.pub The RSA public key used by ssh for version 1 of the SSH protocol.
~/.ssh/known_hosts Contains host keys of SSH servers accessed by the user. This file is very important for ensuring that the SSH client is connecting to the correct SSH server.
For information concerning various directives that can be used in the SSH configuration files, see the ssh_config(5) and sshd_config(5) manual pages.

11.2.2. Starting an OpenSSH Server

In order to run an OpenSSH server, you must have the openssh-server package installed. For more information on how to install new packages, see Section 8.2.4, “Installing Packages”.
To start the sshd daemon in the current session, type the following at a shell prompt as root:
~]# systemctl start sshd.service
To stop the running sshd daemon in the current session, use the following command as root:
~]# systemctl stop sshd.service
If you want the daemon to start automatically at boot time, type as root:
~]# systemctl enable sshd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/sshd.service to /usr/lib/systemd/system/sshd.service.
The sshd daemon depends on the network.target target unit, which is sufficient for static configured network interfaces and for default ListenAddress 0.0.0.0 options. To specify different addresses in the ListenAddress directive and to use a slower dynamic network configuration, add dependency on the network-online.target target unit to the sshd.service unit file. To achieve this, create the /etc/systemd/system/sshd.service.d/local.conf file with the following options:
  [Unit]
  Wants=network-online.target
  After=network-online.target
After this, reload the systemd manager configuration using the following command:
~]# systemctl daemon-reload
For more information on how to manage system services in Red Hat Enterprise Linux, see Chapter 9, Managing Services with systemd.
Note that if you reinstall the system, a new set of identification keys will be created. As a result, clients who had connected to the system with any of the OpenSSH tools before the reinstall will see the following message:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
To prevent this, you can backup the relevant files from the /etc/ssh/ directory. See Table 11.1, “System-wide configuration files” for a complete list, and restore the files whenever you reinstall the system.

11.2.3. Requiring SSH for Remote Connections

For SSH to be truly effective, using insecure connection protocols should be prohibited. Otherwise, a user's password may be protected using SSH for one session, only to be captured later while logging in using Telnet. Some services to disable include telnet, rsh, rlogin, and vsftpd.
For information on how to configure the vsftpd service, see Section 15.2, “FTP”. To learn how to manage system services in Red Hat Enterprise Linux 7, read Chapter 9, Managing Services with systemd.

11.2.4. Using Key-based Authentication

To improve the system security even further, generate SSH key pairs and then enforce key-based authentication by disabling password authentication. To do so, open the /etc/ssh/sshd_config configuration file in a text editor such as vi or nano, and change the PasswordAuthentication option as follows:
PasswordAuthentication no
If you are working on a system other than a new default installation, check that PubkeyAuthentication no has not been set. If connected remotely, not using console or out-of-band access, testing the key-based log in process before disabling password authentication is advised.
To be able to use ssh, scp, or sftp to connect to the server from a client machine, generate an authorization key pair by following the steps below. Note that keys must be generated for each user separately.
Red Hat Enterprise Linux 7 uses SSH Protocol 2 and RSA keys by default (see Section 11.1.3, “Protocol Versions” for more information).

Important

If you complete the steps as root, only root will be able to use the keys.

Note

If you reinstall your system and want to keep previously generated key pairs, backup the ~/.ssh/ directory. After reinstalling, copy it back to your home directory. This process can be done for all users on your system, including root.

11.2.4.1. Generating Key Pairs

To generate an RSA key pair for version 2 of the SSH protocol, follow these steps:
  1. Generate an RSA key pair by typing the following at a shell prompt:
    ~]$ ssh-keygen -t rsa
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/USER/.ssh/id_rsa):
  2. Press Enter to confirm the default location, ~/.ssh/id_rsa, for the newly created key.
  3. Enter a passphrase, and confirm it by entering it again when prompted to do so. For security reasons, avoid using the same password as you use to log in to your account.
    After this, you will be presented with a message similar to this:
    Your identification has been saved in /home/USER/.ssh/id_rsa.
    Your public key has been saved in /home/USER/.ssh/id_rsa.pub.
    The key fingerprint is:
    e7:97:c7:e2:0e:f9:0e:fc:c4:d7:cb:e5:31:11:92:14 USER@penguin.example.com
    The key's randomart image is:
    +--[ RSA 2048]----+
    |             E.  |
    |            . .  |
    |             o . |
    |              . .|
    |        S .    . |
    |         + o o ..|
    |          * * +oo|
    |           O +..=|
    |           o*  o.|
    +-----------------+
  4. By default, the permissions of the ~/.ssh/ directory are set to rwx------ or 700 expressed in octal notation. This is to ensure that only the USER can view the contents. If required, this can be confirmed with the following command:
    ~]$ ls -ld ~/.ssh
    drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
  5. To copy the public key to a remote machine, issue a command in the following format:
     ssh-copy-id user@hostname
    This will copy the most recently modified ~/.ssh/id*.pub public key if it is not yet installed. Alternatively, specify the public key's file name as follows:
    ssh-copy-id -i ~/.ssh/id_rsa.pub user@hostname
    This will copy the content of ~/.ssh/id_rsa.pub into the ~/.ssh/authorized_keys file on the machine to which you want to connect. If the file already exists, the keys are appended to its end.
To generate an ECDSA key pair for version 2 of the SSH protocol, follow these steps:
  1. Generate an ECDSA key pair by typing the following at a shell prompt:
    ~]$ ssh-keygen -t ecdsa
    Generating public/private ecdsa key pair.
    Enter file in which to save the key (/home/USER/.ssh/id_ecdsa):
  2. Press Enter to confirm the default location, ~/.ssh/id_ecdsa, for the newly created key.
  3. Enter a passphrase, and confirm it by entering it again when prompted to do so. For security reasons, avoid using the same password as you use to log in to your account.
    After this, you will be presented with a message similar to this:
    Your identification has been saved in /home/USER/.ssh/id_ecdsa.
    Your public key has been saved in /home/USER/.ssh/id_ecdsa.pub.
    The key fingerprint is:
    fd:1d:ca:10:52:96:21:43:7e:bd:4c:fc:5b:35:6b:63 USER@penguin.example.com
    The key's randomart image is:
    +--[ECDSA  256]---+
    |       .+ +o     |
    |       . =.o     |
    |        o o +  ..|
    |         + + o  +|
    |        S o o oE.|
    |           + oo+.|
    |            + o  |
    |                 |
    |                 |
    +-----------------+
  4. By default, the permissions of the ~/.ssh/ directory are set to rwx------ or 700 expressed in octal notation. This is to ensure that only the USER can view the contents. If required, this can be confirmed with the following command:
    ~]$ ls -ld ~/.ssh
                  ~]$ ls -ld ~/.ssh/
    drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
  5. To copy the public key to a remote machine, issue a command in the following format:
    ssh-copy-id USER@hostname
    This will copy the most recently modified ~/.ssh/id*.pub public key if it is not yet installed. Alternatively, specify the public key's file name as follows:
    ssh-copy-id -i ~/.ssh/id_ecdsa.pub USER@hostname
    This will copy the content of ~/.ssh/id_ecdsa.pub into the ~/.ssh/authorized_keys on the machine to which you want to connect. If the file already exists, the keys are appended to its end.
See Section 11.2.4.2, “Configuring ssh-agent” for information on how to set up your system to remember the passphrase.

Important

The private key is for your personal use only, and it is important that you never give it to anyone.

11.2.4.2. Configuring ssh-agent

To store your passphrase so that you do not have to enter it each time you initiate a connection with a remote machine, you can use the ssh-agent authentication agent. If you are running GNOME, you can configure it to prompt you for your passphrase whenever you log in and remember it during the whole session. Otherwise you can store the passphrase for a certain shell prompt.
To save your passphrase during your GNOME session, follow these steps:
  1. Make sure you have the openssh-askpass package installed. If not, see Section 8.2.4, “Installing Packages” for more information on how to install new packages in Red Hat Enterprise Linux.
  2. Press the Super key to enter the Activities Overview, type Startup Applications and then press Enter. The Startup Applications Preferences tool appears. The tab containing a list of available startup programs will be shown by default. 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 Space bar.
    Startup Applications Preferences

    Figure 11.1. Startup Applications Preferences

  3. Click the Add button on the right, and enter /usr/bin/ssh-add in the Command field.
    Adding new application

    Figure 11.2. Adding new application

  4. Click Add and make sure the checkbox next to the newly added item is selected.
    Enabling the application

    Figure 11.3. Enabling the application

  5. Log out and then log back in. A dialog box will appear prompting you for your passphrase. From this point on, you should not be prompted for a password by ssh, scp, or sftp.
    Entering a passphrase

    Figure 11.4. Entering a passphrase

To save your passphrase for a certain shell prompt, use the following command:
~]$ ssh-add
Enter passphrase for /home/USER/.ssh/id_rsa:
Note that when you log out, your passphrase will be forgotten. You must execute the command each time you log in to a virtual console or a terminal window.

11.3. OpenSSH Clients

To connect to an OpenSSH server from a client machine, you must have the openssh-clients package installed (see Section 8.2.4, “Installing Packages” for more information on how to install new packages in Red Hat Enterprise Linux).

11.3.1. Using the ssh Utility

The ssh utility allows you to log in to a remote machine and execute commands there. It is a secure replacement for the rlogin, rsh, and telnet programs.
Similarly to the telnet command, log in to a remote machine by using the following command:
ssh hostname
For example, to log in to a remote machine named penguin.example.com, type the following at a shell prompt:
~]$ ssh penguin.example.com
This will log you in with the same user name you are using on the local machine. If you want to specify a different user name, use a command in the following form:
ssh username@hostname
For example, to log in to penguin.example.com as USER, type:
~]$ ssh USER@penguin.example.com
The first time you initiate a connection, you will be presented with a message similar to this:
The authenticity of host 'penguin.example.com' can't be established.
ECDSA key fingerprint is 256 da:24:43:0b:2e:c1:3f:a1:84:13:92:01:52:b4:84:ff.
Are you sure you want to continue connecting (yes/no)?
Users should always check if the fingerprint is correct before answering the question in this dialog. The user can ask the administrator of the server to confirm the key is correct. This should be done in a secure and previously agreed way. If the user has access to the server's host keys, the fingerprint can be checked by using the ssh-keygen command as follows:
~]# ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub
256 da:24:43:0b:2e:c1:3f:a1:84:13:92:01:52:b4:84:ff   (ECDSA)
Type yes to accept the key and confirm the connection. You will see a notice that the server has been added to the list of known hosts, and a prompt asking for your password:
Warning: Permanently added 'penguin.example.com' (ECDSA) to the list of known hosts.
USER@penguin.example.com's password:

Important

If the SSH server's host key changes, the client notifies the user that the connection cannot proceed until the server's host key is deleted from the ~/.ssh/known_hosts file. Before doing this, however, contact the system administrator of the SSH server to verify the server is not compromised.
To remove a key from the ~/.ssh/known_hosts file, issue a command as follows:
~]# ssh-keygen -R penguin.example.com
# Host penguin.example.com found: line 15 type ECDSA
/home/USER/.ssh/known_hosts updated.
Original contents retained as /home/USER/.ssh/known_hosts.old
After entering the password, you will be provided with a shell prompt for the remote machine.
Alternatively, the ssh program can be used to execute a command on the remote machine without logging in to a shell prompt:
ssh [username@]hostname command
For example, the /etc/redhat-release file provides information about the Red Hat Enterprise Linux version. To view the contents of this file on penguin.example.com, type:
~]$ ssh USER@penguin.example.com cat /etc/redhat-release
USER@penguin.example.com's password:
Red Hat Enterprise Linux Server release 7.0 (Maipo)
After you enter the correct password, the user name will be displayed, and you will return to your local shell prompt.

11.3.2. Using the scp Utility

scp can be used to transfer files between machines over a secure, encrypted connection. In its design, it is very similar to rcp.
To transfer a local file to a remote system, use a command in the following form:
scp localfile username@hostname:remotefile
For example, if you want to transfer taglist.vim to a remote machine named penguin.example.com, type the following at a shell prompt:
~]$ scp taglist.vim USER@penguin.example.com:.vim/plugin/taglist.vim
USER@penguin.example.com's password:
taglist.vim                                   100%  144KB 144.5KB/s   00:00
Multiple files can be specified at once. To transfer the contents of .vim/plugin/ to the same directory on the remote machine penguin.example.com, type the following command:
~]$ scp .vim/plugin/* USER@penguin.example.com:.vim/plugin/
USER@penguin.example.com's password:
closetag.vim                                  100%   13KB  12.6KB/s   00:00
snippetsEmu.vim                               100%   33KB  33.1KB/s   00:00
taglist.vim                                   100%  144KB 144.5KB/s   00:00
To transfer a remote file to the local system, use the following syntax:
scp username@hostname:remotefile localfile
For instance, to download the .vimrc configuration file from the remote machine, type:
~]$ scp USER@penguin.example.com:.vimrc .vimrc
USER@penguin.example.com's password:
.vimrc                                        100% 2233     2.2KB/s   00:00

11.3.3. Using the sftp Utility

The sftp utility can be used to open a secure, interactive FTP session. In its design, it is similar to ftp except that it uses a secure, encrypted connection.
To connect to a remote system, use a command in the following form:
sftp username@hostname
For example, to log in to a remote machine named penguin.example.com with USER as a user name, type:
~]$ sftp USER@penguin.example.com
USER@penguin.example.com's password:
Connected to penguin.example.com.
sftp>
After you enter the correct password, you will be presented with a prompt. The sftp utility accepts a set of commands similar to those used by ftp (see Table 11.3, “A selection of available sftp commands”).

Table 11.3. A selection of available sftp commands

CommandDescription
ls [directory] List the content of a remote directory. If none is supplied, a current working directory is used by default.
cd directory Change the remote working directory to directory.
mkdir directory Create a remote directory.
rmdir path Remove a remote directory.
put localfile [remotefile] Transfer localfile to a remote machine.
get remotefile [localfile] Transfer remotefile from a remote machine.
For a complete list of available commands, see the sftp(1) manual page.

11.4. More Than a Secure Shell

A secure command-line interface is just the beginning of the many ways SSH can be used. Given the proper amount of bandwidth, X11 sessions can be directed over an SSH channel. Or, by using TCP/IP forwarding, previously insecure port connections between systems can be mapped to specific SSH channels.

11.4.1. X11 Forwarding

To open an X11 session over an SSH connection, use a command in the following form:
ssh -Y username@hostname
For example, to log in to a remote machine named penguin.example.com with USER as a user name, type:
~]$ ssh -Y USER@penguin.example.com
USER@penguin.example.com's password:
When an X program is run from the secure shell prompt, the SSH client and server create a new secure channel, and the X program data is sent over that channel to the client machine transparently.
Note that the X Window system must be installed on the remote system before X11 forwarding can take place. Enter the following command as root to install the X11 package group:
~]# yum group install "X Window System"
For more information on package groups, see Section 8.3, “Working with Package Groups”.
X11 forwarding can be very useful. For example, X11 forwarding can be used to create a secure, interactive session of the Print Settings utility. To do this, connect to the server using ssh and type:
~]$ system-config-printer &
The Print Settings tool will appear, allowing the remote user to safely configure printing on the remote system.

11.4.2. Port Forwarding

SSH can secure otherwise insecure TCP/IP protocols via port forwarding. When using this technique, the SSH server becomes an encrypted conduit to the SSH client.
Port forwarding works by mapping a local port on the client to a remote port on the server. SSH can map any port from the server to any port on the client. Port numbers do not need to match for this technique to work.

Note

Setting up port forwarding to listen on ports below 1024 requires root level access.
To create a TCP/IP port forwarding channel which listens for connections on the localhost, use a command in the following form:
ssh -L local-port:remote-hostname:remote-port username@hostname
For example, to check email on a server called mail.example.com using POP3 through an encrypted connection, use the following command:
~]$ ssh -L 1100:mail.example.com:110 mail.example.com
Once the port forwarding channel is in place between the client machine and the mail server, direct a POP3 mail client to use port 1100 on the localhost to check for new email. Any requests sent to port 1100 on the client system will be directed securely to the mail.example.com server.
If mail.example.com is not running an SSH server, but another machine on the same network is, SSH can still be used to secure part of the connection. However, a slightly different command is necessary:
~]$ ssh -L 1100:mail.example.com:110 other.example.com
In this example, POP3 requests from port 1100 on the client machine are forwarded through the SSH connection on port 22 to the SSH server, other.example.com. Then, other.example.com connects to port 110 on mail.example.com to check for new email. Note that when using this technique, only the connection between the client system and other.example.com SSH server is secure.
Port forwarding can also be used to get information securely through network firewalls. If the firewall is configured to allow SSH traffic via its standard port (that is, port 22) but blocks access to other ports, a connection between two hosts using the blocked ports is still possible by redirecting their communication over an established SSH connection.

Important

Using port forwarding to forward connections in this manner allows any user on the client system to connect to that service. If the client system becomes compromised, the attacker also has access to forwarded services.
System administrators concerned about port forwarding can disable this functionality on the server by specifying a No parameter for the AllowTcpForwarding line in /etc/ssh/sshd_config and restarting the sshd service.

11.5. Additional Resources

For more information on how to configure or connect to an OpenSSH server on Red Hat Enterprise Linux, see the resources listed below.

Installed Documentation

  • sshd(8) — The manual page for the sshd daemon documents available command line options and provides a complete list of supported configuration files and directories.
  • ssh(1) — The manual page for the ssh client application provides a complete list of available command line options and supported configuration files and directories.
  • scp(1) — The manual page for the scp utility provides a more detailed description of this utility and its usage.
  • sftp(1) — The manual page for the sftp utility.
  • ssh-keygen(1) — The manual page for the ssh-keygen utility documents in detail how to use it to generate, manage, and convert authentication keys used by ssh.
  • ssh_config(5) — The manual page named ssh_config documents available SSH client configuration options.
  • sshd_config(5) — The manual page named sshd_config provides a full description of available SSH daemon configuration options.

Online Documentation

  • OpenSSH Home Page — The OpenSSH home page containing further documentation, frequently asked questions, links to the mailing lists, bug reports, and other useful resources.
  • OpenSSL Home Page — The OpenSSL home page containing further documentation, frequently asked questions, links to the mailing lists, and other useful resources.

See Also



[1] A multiplexed connection consists of several signals being sent over a shared, common medium. With SSH, different channels are sent over a common secure connection.

Chapter 12. TigerVNC

TigerVNC (Tiger Virtual Network Computing) is a system for graphical desktop sharing which allows you to remotely control other computers.
TigerVNC works on the client-server principle: a server shares its output (vncserver) and a client (vncviewer) connects to the server.

Note

Unlike in previous Red Hat Enterprise Linux distributions, TigerVNC in Red Hat Enterprise Linux 7 uses the systemd system management daemon for its configuration. The /etc/sysconfig/vncserver configuration file has been replaced by /etc/systemd/system/vncserver@.service.

12.1. VNC Server

vncserver is a utility which starts a VNC (Virtual Network Computing) desktop. It runs Xvnc with appropriate options and starts a window manager on the VNC desktop. vncserver allows users to run separate sessions in parallel on a machine which can then be accessed by any number of clients from anywhere.

12.1.1. Installing VNC Server

To install the TigerVNC server, issue the following command as root:
~]# yum install tigervnc-server

12.1.2. Configuring VNC Server

The VNC server can be configured to start a display for one or more users, provided that accounts for the users exist on the system, with optional parameters such as for display settings, network address and port, and security settings.

Procedure 12.1. Configuring a VNC Display for a Single User

  1. A configuration file named /etc/systemd/system/vncserver@.service is required. To create this file, copy the /usr/lib/systemd/system/vncserver@.service file as root:
    ~]# cp /usr/lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@.service
    There is no need to include the display number in the file name because systemd automatically creates the appropriately named instance in memory on demand, replacing '%i' in the service file by the display number. For a single user it is not necessary to rename the file. For multiple users, a uniquely named service file for each user is required, for example, by adding the user name to the file name in some way. See Section 12.1.2.1, “Configuring VNC Server for Two Users” for details.
  2. Edit /etc/systemd/system/vncserver@.service, replacing USER with the actual user name. Leave the remaining lines of the file unmodified. The -geometry argument specifies the size of the VNC desktop to be created; by default, it is set to 1024x768.
    ExecStart=/usr/sbin/runuser -l USER -c "/usr/bin/vncserver %i -geometry 1280x1024"
    PIDFile=/home/USER/.vnc/%H%i.pid
    
  3. Save the changes.
  4. To make the changes take effect immediately, issue the following command:
    ~]# systemctl daemon-reload
  5. Set the password for the user or users defined in the configuration file. Note that you need to switch from root to USER first.
    ~]# su - USER
    ~]$ vncpasswd
    Password:
    Verify:

    Important

    The stored password is not encrypted; anyone who has access to the password file can find the plain-text password.

12.1.2.1. Configuring VNC Server for Two Users

If you want to configure more than one user on the same machine, create different template-type service files, one for each user.
  1. Create two service files, for example vncserver-USER_1@.service and vncserver-USER_2@.service. In both these files substitute USER with the correct user name.
  2. Set passwords for both users:
    ~]$ su - USER_1
    ~]$ vncpasswd
    Password:
    Verify:
    ~]$ su - USER_2
    ~]$ vncpasswd
    Password:
    Verify:
    

12.1.3. Starting VNC Server

To start or enable the service, specify the display number directly in the command. The file configured above in Procedure 12.1, “Configuring a VNC Display for a Single User” works as a template, in which %i is substituted with the display number by systemd. With a valid display number, execute the following command:
~]# systemctl start vncserver@:display_number.service
You can also enable the service to start automatically at system start. Then, when you log in, vncserver is automatically started. As root, issue a command as follows:
~]# systemctl enable vncserver@:display_number.service
At this point, other users are able to use a VNC viewer program to connect to the VNC server using the display number and password defined. Provided a graphical desktop is installed, an instance of that desktop will be displayed. It will not be the same instance as that currently displayed on the target machine.

12.1.3.1. Configuring VNC Server for Two Users and Two Different Displays

For the two configured VNC servers, vncserver-USER_1@.service and vncserver-USER_2@.service, you can enable different display numbers. For example, the following commands will cause a VNC server for USER_1 to start on display 3, and a VNC server for USER_2 to start on display 5:
~]# systemctl start vncserver-USER_1@:3.service
~]# systemctl start vncserver-USER_2@:5.service

12.1.4. VNC setup based on xinetd with XDMCP for GDM

VNC setup based on xinetd with X Display Manager Control Protocol (XDMCP) for GDM is a useful setup for client systems that consist mainly of thin clients. After the setup, clients are able to access the GDM login window and log in to any system account. The prerequisite for the setup is that the gdm, vnc, vnc-server & and xinetd packages are installed.
~]# yum install gdm tigervnc tigervnc-server xinetd
Service xinetd must be enabled.
~]# systemctl enable xinetd.service
System default target unit should be graphical.target. To get the currently set default target unit, use:
~]# systemctl get-default
The default target unit can be changed by using:
~]# systemctl set-default target_name

Procedure 12.2. Accessing the GDM login window and logging in

  1. Set up GDM to enable XDMCP by editing the /etc/gdm/custom.conf configuration file:
    [xdmcp]
    Enable=true
    
  2. Create a file called /etc/xinetd.d/xvncserver with the following content:
    service service_name
    {
    disable = no
    protocol = tcp
    socket_type = stream
    wait = no
    user = nobody
    server = /usr/bin/Xvnc
    server_args = -inetd -query localhost -once -geometry selected_geometry -depth selected_depth securitytypes=none
    }
    
    In the server_args section, the -query localhost option will make each Xvnc instance query localhost for an xdmcp session. The -depth option specifies the pixel depth (in bits) of the VNC desktop to be created. Acceptable values are 8, 15, 16 and 24 - any other values are likely to cause unpredictable behavior of applications.
  3. Edit file /etc/services to have the service defined. To do this, append the following snippet to the /etc/services file:
    # VNC xinetd GDM base
    service_name 5950/tcp
    
  4. To ensure that the configuration changes take effect, reboot the machine.
    Alternatively, you can run the following. Change init levels to 3 and back to 5 to force gdm to reload.
    # init 3
    # init 5
    
    Verify that gdm is listening on UDP port 177.
    # netstat -anu|grep 177
    udp        0      0 0.0.0.0:177                 0.0.0.0:*
    
    Restart the xinetd service.
    ~]# systemctl restart xinetd.service
    Verify that the xinetd service has loaded the new services.
    # netstat -anpt|grep 595
    tcp        0      0 :::5950                     :::*                        LISTEN      3119/xinetd
    
  5. Test the setup using a vncviewer command:
    # vncviewer localhost:5950
    
    The command will launch a VNC session to the localhost where no password is asked. You will see a GDM login screen, and you will be able to log in to any user account on the system with a valid user name and password. Then you can run the same test on remote connections.
Configure firewall for the setup. Run the firewall configuration tool and add TCP port 5950 to allow incoming connections to the system.
~]# firewall-cmd --permanent --zone=public --add-port=5950/tcp
~]# firewall-cmd --reload

12.1.5. Terminating a VNC Session

Similarly to enabling the vncserver service, you can disable the automatic start of the service at system start:
~]# systemctl disable vncserver@:display_number.service
Or, when your system is running, you can stop the service by issuing the following command as root:
~]# systemctl stop vncserver@:display_number.service

12.2. Sharing an Existing Desktop

By default a logged in user has a desktop provided by X Server on display 0. A user can share their desktop using the TigerVNC server x0vncserver.

Procedure 12.3. Sharing an X Desktop

To share the desktop of a logged in user, using the x0vncserver, proceed as follows:
  1. Enter the following command as root
    ~]# yum install tigervnc-server
  2. Set the VNC password for the user:
    ~]$ vncpasswd
    Password:
    Verify:
  3. Enter the following command as that user:
    ~]$ x0vncserver -PasswordFile=.vnc/passwd -AlwaysShared=1
Provided the firewall is configured to allow connections to port 5900, the remote viewer can now connect to display 0, and view the logged in users desktop. See Section 12.3.2.1, “Configuring the Firewall for VNC” for information on how to configure the firewall.

12.3. VNC Viewer

vncviewer is a program which shows the graphical user interfaces and controls the vncserver remotely.
For operating the vncviewer, there is a pop-up menu containing entries which perform various actions such as switching in and out of full-screen mode or quitting the viewer. Alternatively, you can operate vncviewer through the terminal. Enter vncviewer -h on the command line to list vncviewer's parameters.

12.3.1. Installing VNC Viewer

To install the TigerVNC client, vncviewer, issue the following command as root:
~]# yum install tigervnc

12.3.2. Connecting to VNC Server

Once the VNC server is configured, you can connect to it from any VNC viewer.

Procedure 12.4. Connecting to a VNC Server Using a GUI

  1. Enter the vncviewer command with no arguments, the VNC Viewer: Connection Details utility appears. It prompts for a VNC server to connect to.
  2. If required, to prevent disconnecting any existing VNC connections to the same display, select the option to allow sharing of the desktop as follows:
    1. Select the Options button.
    2. Select the Misc. tab.
    3. Select the Shared button.
    4. Press OK to return to the main menu.
  3. Enter an address and display number to connect to:
    address:display_number
  4. Press Connect to connect to the VNC server display.
  5. You will be prompted to enter the VNC password. This will be the VNC password for the user corresponding to the display number unless a global default VNC password was set.
    A window appears showing the VNC server desktop. Note that this is not the desktop the normal user sees, it is an Xvnc desktop.

Procedure 12.5. Connecting to a VNC Server Using the CLI

  1. Enter the viewer command with the address and display number as arguments:
    vncviewer address:display_number
    Where address is an IP address or host name.
  2. Authenticate yourself by entering the VNC password. This will be the VNC password for the user corresponding to the display number unless a global default VNC password was set.
  3. A window appears showing the VNC server desktop. Note that this is not the desktop the normal user sees, it is the Xvnc desktop.

12.3.2.1. Configuring the Firewall for VNC

When using a non-encrypted connection, firewalld might block the connection. To allow firewalld to pass the VNC packets, you can open specific ports to TCP traffic. When using the -via option, traffic is redirected over SSH which is enabled by default in firewalld.

Note

The default port of VNC server is 5900. To reach the port through which a remote desktop will be accessible, sum the default port and the user's assigned display number. For example, for the second display: 2 + 5900 = 5902.
For displays 0 to 3, make use of firewalld's support for the VNC service by means of the service option as described below. Note that for display numbers greater than 3, the corresponding ports will have to be opened specifically as explained in Procedure 12.7, “Opening Ports in firewalld”.

Procedure 12.6. Enabling VNC Service in firewalld

  1. Run the following command to see the information concerning firewalld settings:
    ~]$ firewall-cmd --list-all
  2. To allow all VNC connections from a specific address, use a command as follows:
    ~]# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.122.116" service name=vnc-server accept'
    success
    Note that these changes will not persist after the next system start. To make permanent changes to the firewall, repeat the commands adding the --permanent option. See the Red Hat Enterprise Linux 7 Security Guide for more information on the use of firewall rich language commands.
  3. To verify the above settings, use a command as follows:
    ~]# firewall-cmd --list-all
    public (default, active)
      interfaces: bond0 bond0.192
      sources:
      services: dhcpv6-client ssh
      ports:
      masquerade: no
      forward-ports:
      icmp-blocks:
      rich rules:
    	rule family="ipv4" source address="192.168.122.116" service name="vnc-server" accept
To open a specific port or range of ports make use of the --add-port option to the firewall-cmd command Line tool. For example, VNC display 4 requires port 5904 to be opened for TCP traffic.

Procedure 12.7. Opening Ports in firewalld

  1. To open a port for TCP traffic in the public zone, issue a command as root as follows:
    ~]# firewall-cmd --zone=public --add-port=5904/tcp
    success
  2. To view the ports that are currently open for the public zone, issue a command as follows:
    ~]# firewall-cmd --zone=public --list-ports
    5904/tcp
A port can be removed using the firewall-cmd --zone=zone --remove-port=number/protocol command.
Note that these changes will not persist after the next system start. To make permanent changes to the firewall, repeat the commands adding the --permanent option. For more information on opening and closing ports in firewalld, see the Red Hat Enterprise Linux 7 Security Guide.

12.3.3. Connecting to VNC Server Using SSH

VNC is a clear text network protocol with no security against possible attacks on the communication. To make the communication secure, you can encrypt your server-client connection by using the -via option. This will create an SSH tunnel between the VNC server and the client.
The format of the command to encrypt a VNC server-client connection is as follows:
vncviewer -via user@host:display_number

Example 12.1. Using the -via Option

  1. To connect to a VNC server using SSH, enter a command as follows:
    ~]$ vncviewer -via USER_2@192.168.2.101:3
  2. When you are prompted to, type the password, and confirm by pressing Enter.
  3. A window with a remote desktop appears on your screen.

Restricting VNC Access

If you prefer only encrypted connections, you can prevent unencrypted connections altogether by using the -localhost option in the systemd.service file, the ExecStart line:
ExecStart=/usr/sbin/runuser -l user -c "/usr/bin/vncserver -localhost %i"
This will stop vncserver from accepting connections from anything but the local host and port-forwarded connections sent using SSH as a result of the -via option.
For more information on using SSH, see Chapter 11, OpenSSH.

12.4. Additional Resources

For more information about TigerVNC, see the resources listed below.

Installed Documentation

  • vncserver(1) — The manual page for the VNC server utility.
  • vncviewer(1) — The manual page for the VNC viewer.
  • vncpasswd(1) — The manual page for the VNC password command.
  • Xvnc(1) — The manual page for the Xvnc server configuration options.
  • x0vncserver(1) — The manual page for the TigerVNC server for sharing existing X servers.

Part V. Servers

This part discusses various topics related to servers such as how to set up a web server or share files and directories over a network.

Chapter 13. Web Servers

A web server is a network service that serves content to a client over the web. This typically means web pages, but any other documents can be served as well. Web servers are also known as HTTP servers, as they use the hypertext transport protocol (HTTP).

13.1. The Apache HTTP Server

The web server available in Red Hat Enterprise Linux 7 is version 2.4 of the Apache HTTP Server, httpd, an open source web server developed by the Apache Software Foundation.
If you are upgrading from a previous release of Red Hat Enterprise Linux, you will need to update the httpd service configuration accordingly. This section reviews some of the newly added features, outlines important changes between Apache HTTP Server 2.4 and version 2.2, and guides you through the update of older configuration files.

13.1.1. Notable Changes

The Apache HTTP Server in Red Hat Enterprise Linux 7 has the following changes compared to Red Hat Enterprise Linux 6:
httpd Service Control
With the migration away from SysV init scripts, server administrators should switch to using the apachectl and systemctl commands to control the service, in place of the service command. The following examples are specific to the httpd service.
The command:
service httpd graceful
is replaced by
apachectl graceful
The systemd unit file for httpd has different behavior from the init script as follows:
  • A graceful restart is used by default when the service is reloaded.
  • A graceful stop is used by default when the service is stopped.
The command:
service httpd configtest
is replaced by
apachectl configtest
Private /tmp
To enhance system security, the systemd unit file runs the httpd daemon using a private /tmp directory, separate to the system /tmp directory.
Configuration Layout
Configuration files which load modules are now placed in the /etc/httpd/conf.modules.d/ directory. Packages that provide additional loadable modules for httpd, such as php, will place a file in this directory. An Include directive before the main section of the /etc/httpd/conf/httpd.conf file is used to include files within the /etc/httpd/conf.modules.d/ directory. This means any configuration files within conf.modules.d/ are processed before the main body of httpd.conf. An IncludeOptional directive for files within the /etc/httpd/conf.d/ directory is placed at the end of the httpd.conf file. This means the files within /etc/httpd/conf.d/ are now processed after the main body of httpd.conf.
Some additional configuration files are provided by the httpd package itself:
  • /etc/httpd/conf.d/autoindex.conf — This configures mod_autoindex directory indexing.
  • /etc/httpd/conf.d/userdir.conf — This configures access to user directories, for example, http://example.com/~username/; such access is disabled by default for security reasons.
  • /etc/httpd/conf.d/welcome.conf — As in previous releases, this configures the welcome page displayed for http://localhost/ when no content is present.
Default Configuration
A minimal httpd.conf file is now provided by default. Many common configuration settings, such as Timeout or KeepAlive are no longer explicitly configured in the default configuration; hard-coded settings will be used instead, by default. The hard-coded default settings for all configuration directives are specified in the manual. See the section called “Installable Documentation” for more information.
Incompatible Syntax Changes
If migrating an existing configuration from httpd 2.2 to httpd 2.4, a number of backwards-incompatible changes to the httpd configuration syntax were made which will require changes. See the following Apache document for more information on upgrading http://httpd.apache.org/docs/2.4/upgrading.html
Processing Model
In previous releases of Red Hat Enterprise Linux, different multi-processing models (MPM) were made available as different httpd binaries: the forked model, prefork, as /usr/sbin/httpd, and the thread-based model worker as /usr/sbin/httpd.worker.
In Red Hat Enterprise Linux 7, only a single httpd binary is used, and three MPMs are available as loadable modules: worker, prefork (default), and event. Edit the configuration file /etc/httpd/conf.modules.d/00-mpm.conf as required, by adding and removing the comment character # so that only one of the three MPM modules is loaded.
Packaging Changes
The LDAP authentication and authorization modules are now provided in a separate sub-package, mod_ldap. The new module mod_session and associated helper modules are provided in a new sub-package, mod_session. The new modules mod_proxy_html and mod_xml2enc are provided in a new sub-package, mod_proxy_html. These packages are all in the Optional channel.

Note

Before subscribing to the Optional and Supplementary channels see the Scope of Coverage Details. If you decide to install packages from these channels, follow the steps documented in the article called How to access Optional and Supplementary channels, and -devel packages using Red Hat Subscription Manager (RHSM)? on the Red Hat Customer Portal.
Packaging Filesystem Layout
The /var/cache/mod_proxy/ directory is no longer provided; instead, the /var/cache/httpd/ directory is packaged with a proxy and ssl subdirectory.
Packaged content provided with httpd has been moved from /var/www/ to /usr/share/httpd/:
  • /usr/share/httpd/icons/ — The directory containing a set of icons used with directory indices, previously contained in /var/www/icons/, has moved to /usr/share/httpd/icons/. Available at http://localhost/icons/ in the default configuration; the location and the availability of the icons is configurable in the /etc/httpd/conf.d/autoindex.conf file.
  • /usr/share/httpd/manual/ — The /var/www/manual/ has moved to /usr/share/httpd/manual/. This directory, contained in the httpd-manual package, contains the HTML version of the manual for httpd. Available at http://localhost/manual/ if the package is installed, the location and the availability of the manual is configurable in the /etc/httpd/conf.d/manual.conf file.
  • /usr/share/httpd/error/ — The /var/www/error/ has moved to /usr/share/httpd/error/. Custom multi-language HTTP error pages. Not configured by default, the example configuration file is provided at /usr/share/doc/httpd-VERSION/httpd-multilang-errordoc.conf.
Authentication, Authorization and Access Control
The configuration directives used to control authentication, authorization and access control have changed significantly. Existing configuration files using the Order, Deny and Allow directives should be adapted to use the new Require syntax. See the following Apache document for more information http://httpd.apache.org/docs/2.4/howto/auth.html
suexec
To improve system security, the suexec binary is no longer installed as if by the root user; instead, it has file system capability bits set which allow a more restrictive set of permissions. In conjunction with this change, the suexec binary no longer uses the /var/log/httpd/suexec.log logfile. Instead, log messages are sent to syslog; by default these will appear in the /var/log/secure log file.
Module Interface
Third-party binary modules built against httpd 2.2 are not compatible with httpd 2.4 due to changes to the httpd module interface. Such modules will need to be adjusted as necessary for the httpd 2.4 module interface, and then rebuilt. A detailed list of the API changes in version 2.4 is available here: http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html.
The apxs binary used to build modules from source has moved from /usr/sbin/apxs to /usr/bin/apxs.
Removed modules
List of httpd modules removed in Red Hat Enterprise Linux 7:
mod_auth_mysql, mod_auth_pgsql
httpd 2.4 provides SQL database authentication support internally in the mod_authn_dbd module.
mod_perl
mod_perl is not officially supported with httpd 2.4 by upstream.
mod_authz_ldap
httpd 2.4 provides LDAP support in sub-package mod_ldap using mod_authnz_ldap.

13.1.2. Updating the Configuration

To update the configuration files from the Apache HTTP Server version 2.2, take the following steps:
  1. Make sure all module names are correct, since they may have changed. Adjust the LoadModule directive for each module that has been renamed.
  2. Recompile all third party modules before attempting to load them. This typically means authentication and authorization modules.
  3. If you use the mod_userdir module, make sure the UserDir directive indicating a directory name (typically public_html) is provided.
  4. If you use the Apache HTTP Secure Server, see Section 13.1.8, “Enabling the mod_ssl Module” for important information on enabling the Secure Sockets Layer (SSL) protocol.
Note that you can check the configuration for possible errors by using the following command:
~]# apachectl configtest
Syntax OK
For more information on upgrading the Apache HTTP Server configuration from version 2.2 to 2.4, see http://httpd.apache.org/docs/2.4/upgrading.html.

13.1.3. Running the httpd Service

This section describes how to start, stop, restart, and check the current status of the Apache HTTP Server. To be able to use the httpd service, make sure you have the httpd installed. You can do so by using the following command:
~]# yum install httpd
For more information on the concept of targets and how to manage system services in Red Hat Enterprise Linux in general, see Chapter 9, Managing Services with systemd.

13.1.3.1. Starting the Service

To run the httpd service, type the following at a shell prompt as root:
~]# systemctl start httpd.service
If you want the service to start automatically at boot time, use the following command:
~]# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

Note

If running the Apache HTTP Server as a secure server, a password may be required after the machine boots if using an encrypted private SSL key.

13.1.3.2. Stopping the Service

To stop the running httpd service, type the following at a shell prompt as root:
~]# systemctl stop httpd.service
To prevent the service from starting automatically at boot time, type:
~]# systemctl disable httpd.service
Removed symlink /etc/systemd/system/multi-user.target.wants/httpd.service.

13.1.3.3. Restarting the Service

There are three different ways to restart a running httpd service:
  1. To restart the service completely, enter the following command as root:
    ~]# systemctl restart httpd.service
    This stops the running httpd service and immediately starts it again. Use this command after installing or removing a dynamically loaded module such as PHP.
  2. To only reload the configuration, as root, type:
    ~]# systemctl reload httpd.service
    This causes the running httpd service to reload its configuration file. Any requests currently being processed will be interrupted, which may cause a client browser to display an error message or render a partial page.
  3. To reload the configuration without affecting active requests, enter the following command as root:
    ~]# apachectl graceful
    This causes the running httpd service to reload its configuration file. Any requests currently being processed will continue to use the old configuration.
For more information on how to manage system services in Red Hat Enterprise Linux 7, see Chapter 9, Managing Services with systemd.

13.1.3.4. Verifying the Service Status

To verify that the httpd service is running, type the following at a shell prompt:
~]# systemctl is-active httpd.service
active

13.1.4. Editing the Configuration Files

When the httpd service is started, by default, it reads the configuration from locations that are listed in Table 13.1, “The httpd service configuration files”.

Table 13.1. The httpd service configuration files

Path Description
/etc/httpd/conf/httpd.conf The main configuration file.
/etc/httpd/conf.d/ An auxiliary directory for configuration files that are included in the main configuration file.
Although the default configuration should be suitable for most situations, it is a good idea to become at least familiar with some of the more important configuration options. Note that for any changes to take effect, the web server has to be restarted first. See Section 13.1.3.3, “Restarting the Service” for more information on how to restart the httpd service.
To check the configuration for possible errors, type the following at a shell prompt:
~]# apachectl configtest
Syntax OK
To make the recovery from mistakes easier, it is recommended that you make a copy of the original file before editing it.

13.1.5. Working with Modules

Being a modular application, the httpd service is distributed along with a number of Dynamic Shared Objects (DSOs), which can be dynamically loaded or unloaded at runtime as necessary. On Red Hat Enterprise Linux 7, these modules are located in /usr/lib64/httpd/modules/.

13.1.5.1. Loading a Module

To load a particular DSO module, use the LoadModule directive. Note that modules provided by a separate package often have their own configuration file in the /etc/httpd/conf.d/ directory.

Example 13.1. Loading the mod_ssl DSO

LoadModule ssl_module modules/mod_ssl.so
Once you are finished, restart the web server to reload the configuration. See Section 13.1.3.3, “Restarting the Service” for more information on how to restart the httpd service.

13.1.5.2. Writing a Module

If you intend to create a new DSO module, make sure you have the httpd-devel package installed. To do so, enter the following command as root:
~]# yum install httpd-devel
This package contains the include files, the header files, and the APache eXtenSion (apxs) utility required to compile a module.
Once written, you can build the module with the following command:
~]# apxs -i -a -c module_name.c
If the build was successful, you should be able to load the module the same way as any other module that is distributed with the Apache HTTP Server.

13.1.6. Setting Up Virtual Hosts

The Apache HTTP Server's built in virtual hosting allows the server to provide different information based on which IP address, host name, or port is being requested.
To create a name-based virtual host, copy the example configuration file /usr/share/doc/httpd-VERSION/httpd-vhosts.conf into the /etc/httpd/conf.d/ directory, and replace the @@Port@@ and @@ServerRoot@@ placeholder values. Customize the options according to your requirements as shown in Example 13.2, “Example virtual host configuration”.

Example 13.2. Example virtual host configuration

<VirtualHost *:80>
    ServerAdmin webmaster@penguin.example.com
    DocumentRoot "/www/docs/penguin.example.com"
    ServerName penguin.example.com
    ServerAlias www.penguin.example.com
    ErrorLog "/var/log/httpd/dummy-host.example.com-error_log"
    CustomLog "/var/log/httpd/dummy-host.example.com-access_log" common
</VirtualHost>
Note that ServerName must be a valid DNS name assigned to the machine. The <VirtualHost> container is highly customizable, and accepts most of the directives available within the main server configuration. Directives that are not supported within this container include User and Group, which were replaced by SuexecUserGroup.

Note

If you configure a virtual host to listen on a non-default port, make sure you update the Listen directive in the global settings section of the /etc/httpd/conf/httpd.conf file accordingly.
To activate a newly created virtual host, the web server has to be restarted first. See Section 13.1.3.3, “Restarting the Service” for more information on how to restart the httpd service.

13.1.7. Setting Up an SSL Server

Secure Sockets Layer (SSL) is a cryptographic protocol that allows a server and a client to communicate securely. Along with its extended and improved version called Transport Layer Security (TLS), it ensures both privacy and data integrity. The Apache HTTP Server in combination with mod_ssl, a module that uses the OpenSSL toolkit to provide the SSL/TLS support, is commonly referred to as the SSL server. Red Hat Enterprise Linux also supports the use of Mozilla NSS as the TLS implementation. Support for Mozilla NSS is provided by the mod_nss module.
Unlike an HTTP connection that can be read and possibly modified by anybody who is able to intercept it, the use of SSL/TLS over HTTP, referred to as HTTPS, prevents any inspection or modification of the transmitted content. This section provides basic information on how to enable this module in the Apache HTTP Server configuration, and guides you through the process of generating private keys and self-signed certificates.

13.1.7.1. An Overview of Certificates and Security

Secure communication is based on the use of keys. In conventional or symmetric cryptography, both ends of the transaction have the same key they can use to decode each other's transmissions. On the other hand, in public or asymmetric cryptography, two keys co-exist: a private key that is kept a secret, and a public key that is usually shared with the public. While the data encoded with the public key can only be decoded with the private key, data encoded with the private key can in turn only be decoded with the public key.
To provide secure communications using SSL, an SSL server must use a digital certificate signed by a Certificate Authority (CA). The certificate lists various attributes of the server (that is, the server host name, the name of the company, its location, etc.), and the signature produced using the CA's private key. This signature ensures that a particular certificate authority has signed the certificate, and that the certificate has not been modified in any way.
When a web browser establishes a new SSL connection, it checks the certificate provided by the web server. If the certificate does not have a signature from a trusted CA, or if the host name listed in the certificate does not match the host name used to establish the connection, it refuses to communicate with the server and usually presents a user with an appropriate error message.
By default, most web browsers are configured to trust a set of widely used certificate authorities. Because of this, an appropriate CA should be chosen when setting up a secure server, so that target users can trust the connection, otherwise they will be presented with an error message, and will have to accept the certificate manually. Since encouraging users to override certificate errors can allow an attacker to intercept the connection, you should use a trusted CA whenever possible. For more information on this, see Table 13.2, “Information about CA lists used by common web browsers”.

Table 13.2. Information about CA lists used by common web browsers

When setting up an SSL server, you need to generate a certificate request and a private key, and then send the certificate request, proof of the company's identity, and payment to a certificate authority. Once the CA verifies the certificate request and your identity, it will send you a signed certificate you can use with your server. Alternatively, you can create a self-signed certificate that does not contain a CA signature, and thus should be used for testing purposes only.

13.1.8. Enabling the mod_ssl Module

If you intend to set up an SSL or HTTPS server using mod_ssl, you cannot have the another application or module, such as mod_nss configured to use the same port. Port 443 is the default port for HTTPS.
To set up an SSL server using the mod_ssl module and the OpenSSL toolkit, install the mod_ssl and openssl packages. Enter the following command as root:
~]# yum install mod_ssl openssl
This will create the mod_ssl configuration file at /etc/httpd/conf.d/ssl.conf, which is included in the main Apache HTTP Server configuration file by default. For the module to be loaded, restart the httpd service as described in Section 13.1.3.3, “Restarting the Service”.

Important

Due to the vulnerability described in POODLE: SSLv3 vulnerability (CVE-2014-3566), Red Hat recommends disabling SSL and using only TLSv1.1 or TLSv1.2. Backwards compatibility can be achieved using TLSv1.0. Many products Red Hat supports have the ability to use SSLv2 or SSLv3 protocols, or enable them by default. However, the use of SSLv2 or SSLv3 is now strongly recommended against.

13.1.8.1. Enabling and Disabling SSL and TLS in mod_ssl

To disable and enable specific versions of the SSL and TLS protocol, either do it globally by adding the SSLProtocol directive in the ## SSL Global Context section of the configuration file and removing it everywhere else, or edit the default entry under # SSL Protocol support in all VirtualHost sections. If you do not specify it in the per-domain VirtualHost section then it will inherit the settings from the global section. To make sure that a protocol version is being disabled the administrator should either only specify SSLProtocol in the SSL Global Context section, or specify it in all per-domain VirtualHost sections.

Procedure 13.1. Disable SSLv2 and SSLv3

To disable SSL version 2 and SSL version 3, which implies enabling everything except SSL version 2 and SSL version 3, in all VirtualHost sections, proceed as follows:
  1. As root, open the /etc/httpd/conf.d/ssl.conf file and search for all instances of the SSLProtocol directive. By default, the configuration file contains one section that looks as follows:
    ~]# vi /etc/httpd/conf.d/ssl.conf
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol all -SSLv2
    This section is within the VirtualHost section.
  2. Edit the SSLProtocol line as follows:
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol all -SSLv2 -SSLv3
    Repeat this action for all VirtualHost sections. Save and close the file.
  3. Verify that all occurrences of the SSLProtocol directive have been changed as follows:
    ~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf
    SSLProtocol all -SSLv2 -SSLv3
    This step is particularly important if you have more than the one default VirtualHost section.
  4. Restart the Apache daemon as follows:
    ~]# systemctl restart httpd
    Note that any sessions will be interrupted.

Procedure 13.2. Disable All SSL and TLS Protocols Except TLS 1 and Up

To disable all SSL and TLS protocol versions except TLS version 1 and higher, proceed as follows:
  1. As root, open the /etc/httpd/conf.d/ssl.conf file and search for all instances of SSLProtocol directive. By default the file contains one section that looks as follows:
    ~]# vi /etc/httpd/conf.d/ssl.conf
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol all -SSLv2
  2. Edit the SSLProtocol line as follows:
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
    Save and close the file.
  3. Verify the change as follows:
    ~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf 
    SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
  4. Restart the Apache daemon as follows:
    ~]# systemctl restart httpd
    Note that any sessions will be interrupted.

Procedure 13.3. Testing the Status of SSL and TLS Protocols

To check which versions of SSL and TLS are enabled or disabled, make use of the openssl s_client -connect command. The command has the following form:
openssl s_client -connect hostname:port -protocol
Where port is the port to test and protocol is the protocol version to test for. To test the SSL server running locally, use localhost as the host name. For example, to test the default port for secure HTTPS connections, port 443 to see if SSLv3 is enabled, issue a command as follows:
  1. ~]# openssl s_client -connect localhost:443 -ssl3
    CONNECTED(00000003)
    139809943877536:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40
    139809943877536:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:
    output omitted
    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : SSLv3
    output truncated
    The above output indicates that the handshake failed and therefore no cipher was negotiated.
  2. ~]$ openssl s_client -connect localhost:443 -tls1_2
    CONNECTED(00000003)
    depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = localhost.localdomain, emailAddress = root@localhost.localdomain
    output omitted
    New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
    Server public key is 2048 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : TLSv1.2
    output truncated
    The above output indicates that no failure of the handshake occurred and a set of ciphers was negotiated.
The openssl s_client command options are documented in the s_client(1) manual page.
For more information on the SSLv3 vulnerability and how to test for it, see the Red Hat Knowledgebase article POODLE: SSLv3 vulnerability (CVE-2014-3566).

13.1.9. Enabling the mod_nss Module

If you intend to set up an HTTPS server using mod_nss, you cannot have the mod_ssl package installed with its default settings as mod_ssl will use port 443 by default, however this is the default HTTPS port. If at all possible, remove the package.
To remove mod_ssl, enter the following command as root:
~]# yum remove mod_ssl

Note

If mod_ssl is required for other purposes, modify the /etc/httpd/conf.d/ssl.conf file to use a port other than 443 to prevent mod_ssl conflicting with mod_nss when its port to listen on is changed to 443.
Only one module can own a port, therefore mod_nss and mod_ssl can only co-exist at the same time if they use unique ports. For this reason mod_nss by default uses 8443, but the default port for HTTPS is port 443. The port is specified by the Listen directive as well as in the VirtualHost name or address.
Everything in NSS is associated with a token. The software token exists in the NSS database but you can also have a physical token containing certificates. With OpenSSL, discrete certificates and private keys are held in PEM files. With NSS, these are stored in a database. Each certificate and key is associated with a token and each token can have a password protecting it. This password is optional, but if a password is used then the Apache HTTP server needs a copy of it in order to open the database without user intervention at system start.

Procedure 13.4. Configuring mod_nss

  1. Install mod_nss as root:
    ~]# yum install mod_nss
    This will create the mod_nss configuration file at /etc/httpd/conf.d/nss.conf. The /etc/httpd/conf.d/ directory is included in the main Apache HTTP Server configuration file by default. For the module to be loaded, restart the httpd service as described in Section 13.1.3.3, “Restarting the Service”.
  2. As root, open the /etc/httpd/conf.d/nss.conf file and search for all instances of the Listen directive.
    Edit the Listen 8443 line as follows:
    Listen 443
    Port 443 is the default port for HTTPS.
  3. Edit the default VirtualHost _default_:8443 line as follows:
    VirtualHost _default_:443
    Edit any other non-default virtual host sections if they exist. Save and close the file.
  4. Mozilla NSS stores certificates in a server certificate database indicated by the NSSCertificateDatabase directive in the /etc/httpd/conf.d/nss.conf file. By default the path is set to /etc/httpd/alias, the NSS database created during installation.
    To view the default NSS database, issue a command as follows:
    ~]# certutil -L -d /etc/httpd/alias
    
    Certificate Nickname                                         Trust Attributes
                                                                 SSL,S/MIME,JAR/XPI
    
    cacert                                                       CTu,Cu,Cu
    Server-Cert                                                  u,u,u
    alpha                                                        u,pu,u
    In the above command output, Server-Cert is the default NSSNickname. The -L option lists all the certificates, or displays information about a named certificate, in a certificate database. The -d option specifies the database directory containing the certificate and key database files. See the certutil(1) man page for more command line options.
  5. To configure mod_nss to use another database, edit the NSSCertificateDatabase line in the /etc/httpd/conf.d/nss.conf file. The default file has the following lines within the VirtualHost section.
    #   Server Certificate Database:
    #   The NSS security database directory that holds the certificates and
    #   keys. The database consists of 3 files: cert8.db, key3.db and secmod.db.
    #   Provide the directory that these files exist.
    NSSCertificateDatabase /etc/httpd/alias
    In the above command output, alias is the default NSS database directory, /etc/httpd/alias/.
  6. To apply a password to the default NSS certificate database, use the following command as root:
    ~]# certutil -W -d /etc/httpd/alias
    Enter Password or Pin for "NSS Certificate DB":
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    
    Enter new password:
    Re-enter password:
    Password changed successfully.
  7. Before deploying the HTTPS server, create a new certificate database using a certificate signed by a certificate authority (CA).

    Example 13.3. Adding a Certificate to the Mozilla NSS database

    The certutil command is used to add a CA certificate to the NSS database files:
    certutil -d /etc/httpd/nss-db-directory/ -A -n "CA_certificate" -t CT,, -a -i certificate.pem
    The above command adds a CA certificate stored in a PEM-formatted file named certificate.pem. The -d option specifies the NSS database directory containing the certificate and key database files, the -n option sets a name for the certificate, -t CT,, means that the certificate is trusted to be used in TLS clients and servers. The -A option adds an existing certificate to a certificate database. If the database does not exist it will be created. The -a option allows the use of ASCII format for input or output, and the -i option passes the certificate.pem input file to the command.
    See the certutil(1) man page for more command line options.
  8. The NSS database should be password protected to safeguard the private key.

    Example 13.4. Setting a Password for a Mozilla NSS database

    The certutil tool can be used set a password for an NSS database as follows:
    certutil -W -d /etc/httpd/nss-db-directory/
    For example, for the default database, issue a command as root as follows:
    ~]# certutil -W -d /etc/httpd/alias
    Enter Password or Pin for "NSS Certificate DB":
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    
    Enter new password: 
    Re-enter password: 
    Password changed successfully.
  9. Configure mod_nss to use the NSS internal software token by changing the line with the NSSPassPhraseDialog directive as follows:
    ~]# vi /etc/httpd/conf.d/nss.conf
    NSSPassPhraseDialog file:/etc/httpd/password.conf
    This is to avoid manual password entry on system start. The software token exists in the NSS database but you can also have a physical token containing your certificates.
  10. If the SSL Server Certificate contained in the NSS database is an RSA certificate, make certain that the NSSNickname parameter is uncommented and matches the nickname displayed in step 4 above:
    ~]# vi /etc/httpd/conf.d/nss.conf
    NSSNickname Server-Cert
    If the SSL Server Certificate contained in the NSS database is an ECC certificate, make certain that the NSSECCNickname parameter is uncommented and matches the nickname displayed in step 4 above:
    ~]# vi /etc/httpd/conf.d/nss.conf
    NSSECCNickname Server-Cert
    Make certain that the NSSCertificateDatabase parameter is uncommented and points to the NSS database directory displayed in step 4 or configured in step 5 above:
    ~]# vi /etc/httpd/conf.d/nss.conf
    NSSCertificateDatabase /etc/httpd/alias
    Replace /etc/httpd/alias with the path to the certificate database to be used.
  11. Create the /etc/httpd/password.conf file as root:
    ~]# vi /etc/httpd/password.conf
    Add a line with the following form:
    internal:password
    Replacing password with the password that was applied to the NSS security databases in step 6 above.
  12. Apply the appropriate ownership and permissions to the /etc/httpd/password.conf file:
    ~]# chgrp apache /etc/httpd/password.conf
    ~]# chmod 640 /etc/httpd/password.conf
    ~]# ls -l /etc/httpd/password.conf
    -rw-r-----. 1 root apache 10 Dec  4 17:13 /etc/httpd/password.conf
  13. To configure mod_nss to use the NSS the software token in /etc/httpd/password.conf, edit /etc/httpd/conf.d/nss.conf as follows:
    ~]# vi /etc/httpd/conf.d/nss.conf
  14. Restart the Apache server for the changes to take effect as described in Section 13.1.3.3, “Restarting the Service”

Important

Due to the vulnerability described in POODLE: SSLv3 vulnerability (CVE-2014-3566), Red Hat recommends disabling SSL and using only TLSv1.1 or TLSv1.2. Backwards compatibility can be achieved using TLSv1.0. Many products Red Hat supports have the ability to use SSLv2 or SSLv3 protocols, or enable them by default. However, the use of SSLv2 or SSLv3 is now strongly recommended against.

13.1.9.1. Enabling and Disabling SSL and TLS in mod_nss

To disable and enable specific versions of the SSL and TLS protocol, either do it globally by adding the NSSProtocol directive in the ## SSL Global Context section of the configuration file and removing it everywhere else, or edit the default entry under # SSL Protocol in all VirtualHost sections. If you do not specify it in the per-domain VirtualHost section then it will inherit the settings from the global section. To make sure that a protocol version is being disabled the administrator should either only specify NSSProtocol in the SSL Global Context section, or specify it in all per-domain VirtualHost sections.

Procedure 13.5. Disable All SSL and TLS Protocols Except TLS 1 and Up in mod_nss

To disable all SSL and TLS protocol versions except TLS version 1 and higher, proceed as follows:
  1. As root, open the /etc/httpd/conf.d/nss.conf file and search for all instances of the NSSProtocol directive. By default, the configuration file contains one section that looks as follows:
    ~]# vi /etc/httpd/conf.d/nss.conf
    #   SSL Protocol:
    output omitted
    #   Since all protocol ranges are completely inclusive, and no protocol in the
    #   middle of a range may be excluded, the entry "NSSProtocol SSLv3,TLSv1.1"
    #   is identical to the entry "NSSProtocol SSLv3,TLSv1.0,TLSv1.1".
    NSSProtocol SSLv3,TLSv1.0,TLSv1.1
    This section is within the VirtualHost section.
  2. Edit the NSSProtocol line as follows:
    #   SSL Protocol:
    NSSProtocol TLSv1.0,TLSv1.1
    Repeat this action for all VirtualHost sections.
  3. Edit the Listen 8443 line as follows:
    Listen 443
  4. Edit the default VirtualHost _default_:8443 line as follows:
    VirtualHost _default_:443
    Edit any other non-default virtual host sections if they exist. Save and close the file.
  5. Verify that all occurrences of the NSSProtocol directive have been changed as follows:
    ~]# grep NSSProtocol /etc/httpd/conf.d/nss.conf
    #   middle of a range may be excluded, the entry "NSSProtocol SSLv3,TLSv1.1"
    #   is identical to the entry "NSSProtocol SSLv3,TLSv1.0,TLSv1.1".
    NSSProtocol TLSv1.0,TLSv1.1
    This step is particularly important if you have more than one VirtualHost section.
  6. Restart the Apache daemon as follows:
    ~]# service httpd restart
    Note that any sessions will be interrupted.

Procedure 13.6. Testing the Status of SSL and TLS Protocols in mod_nss

To check which versions of SSL and TLS are enabled or disabled in mod_nss, make use of the openssl s_client -connect command. Install the openssl package as root:
~]# yum install openssl
The openssl s_client -connect command has the following form:
openssl s_client -connect hostname:port -protocol
Where port is the port to test and protocol is the protocol version to test for. To test the SSL server running locally, use localhost as the host name. For example, to test the default port for secure HTTPS connections, port 443 to see if SSLv3 is enabled, issue a command as follows:
  1. ~]# openssl s_client -connect localhost:443 -ssl3
    CONNECTED(00000003)
    3077773036:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
    output omitted
    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : SSLv3
    output truncated
    The above output indicates that the handshake failed and therefore no cipher was negotiated.
  2. ~]$ openssl s_client -connect localhost:443 -tls1
    CONNECTED(00000003)
    depth=1 C = US, O = example.com, CN = Certificate Shack
    output omitted
    New, TLSv1/SSLv3, Cipher is AES128-SHA
    Server public key is 1024 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : TLSv1
    output truncated
    The above output indicates that no failure of the handshake occurred and a set of ciphers was negotiated.
The openssl s_client command options are documented in the s_client(1) manual page.
For more information on the SSLv3 vulnerability and how to test for it, see the Red Hat Knowledgebase article POODLE: SSLv3 vulnerability (CVE-2014-3566).

13.1.10. Using an Existing Key and Certificate

If you have a previously created key and certificate, you can configure the SSL server to use these files instead of generating new ones. There are only two situations where this is not possible:
  1. You are changing the IP address or domain name.
    Certificates are issued for a particular IP address and domain name pair. If one of these values changes, the certificate becomes invalid.
  2. You have a certificate from VeriSign, and you are changing the server software.
    VeriSign, a widely used certificate authority, issues certificates for a particular software product, IP address, and domain name. Changing the software product renders the certificate invalid.
In either of the above cases, you will need to obtain a new certificate. For more information on this topic, see Section 13.1.11, “Generating a New Key and Certificate”.
If you want to use an existing key and certificate, move the relevant files to the /etc/pki/tls/private/ and /etc/pki/tls/certs/ directories respectively. You can do so by issuing the following commands as root:
~]# mv key_file.key /etc/pki/tls/private/hostname.key
~]# mv certificate.crt /etc/pki/tls/certs/hostname.crt
Then add the following lines to the /etc/httpd/conf.d/ssl.conf configuration file:
SSLCertificateFile /etc/pki/tls/certs/hostname.crt
SSLCertificateKeyFile /etc/pki/tls/private/hostname.key
To load the updated configuration, restart the httpd service as described in Section 13.1.3.3, “Restarting the Service”.

Example 13.5. Using a key and certificate from the Red Hat Secure Web Server

~]# mv /etc/httpd/conf/httpsd.key /etc/pki/tls/private/penguin.example.com.key
~]# mv /etc/httpd/conf/httpsd.crt /etc/pki/tls/certs/penguin.example.com.crt

13.1.11. Generating a New Key and Certificate

In order to generate a new key and certificate pair, the crypto-utils package must be installed on the system. To install it, enter the following command as root:
~]# yum install crypto-utils
This package provides a set of tools to generate and manage SSL certificates and private keys, and includes genkey, the Red Hat Keypair Generation utility that will guide you through the key generation process.

Important

If the server already has a valid certificate and you are replacing it with a new one, specify a different serial number. This ensures that client browsers are notified of this change, update to this new certificate as expected, and do not fail to access the page. To create a new certificate with a custom serial number, as root, use the following command instead of genkey:
~]# openssl req -x509 -new -set_serial number -key hostname.key -out hostname.crt

Note

If there already is a key file for a particular host name in your system, genkey will refuse to start. In this case, remove the existing file using the following command as root:
~]# rm /etc/pki/tls/private/hostname.key
To run the utility enter the genkey command as root, followed by the appropriate host name (for example, penguin.example.com):
~]# genkey hostname
To complete the key and certificate creation, take the following steps:
  1. Review the target locations in which the key and certificate will be stored.
    Running the genkey utility

    Figure 13.1. Running the genkey utility

    Use the Tab key to select the Next button, and press Enter to proceed to the next screen.
  2. Using the up and down arrow keys, select a suitable key size. Note that while a larger key increases the security, it also increases the response time of your server. The NIST recommends using 2048 bits. See NIST Special Publication 800-131A.
    Selecting the key size

    Figure 13.2. Selecting the key size

    Once finished, use the Tab key to select the Next button, and press Enter to initiate the random bits generation process. Depending on the selected key size, this may take some time.
  3. Decide whether you want to send a certificate request to a certificate authority.
    Generating a certificate request

    Figure 13.3. Generating a certificate request

    Use the Tab key to select Yes to compose a certificate request, or No to generate a self-signed certificate. Then press Enter to confirm your choice.
  4. Using the Spacebar key, enable ([*]) or disable ([ ]) the encryption of the private key.
    Encrypting the private key

    Figure 13.4. Encrypting the private key

    Use the Tab key to select the Next button, and press Enter to proceed to the next screen.
  5. If you have enabled the private key encryption, enter an adequate passphrase. Note that for security reasons, it is not displayed as you type, and it must be at least five characters long.
    Entering a passphrase

    Figure 13.5. Entering a passphrase

    Use the Tab key to select the Next button, and press Enter to proceed to the next screen.

    Important

    Entering the correct passphrase is required in order for the server to start. If you lose it, you will need to generate a new key and certificate.
  6. Customize the certificate details.
    Specifying certificate information

    Figure 13.6. Specifying certificate information

    Use the Tab key to select the Next button, and press Enter to finish the key generation.
  7. If you have previously enabled the certificate request generation, you will be prompted to send it to a certificate authority.
    Instructions on how to send a certificate request

    Figure 13.7. Instructions on how to send a certificate request

    Press Enter to return to a shell prompt.
Once generated, add the key and certificate locations to the /etc/httpd/conf.d/ssl.conf configuration file:
SSLCertificateFile /etc/pki/tls/certs/hostname.crt
SSLCertificateKeyFile /etc/pki/tls/private/hostname.key
Finally, restart the httpd service as described in Section 13.1.3.3, “Restarting the Service”, so that the updated configuration is loaded.

13.1.12. Configure the Firewall for HTTP and HTTPS Using the Command Line

Red Hat Enterprise Linux does not allow HTTP and HTTPS traffic by default. To enable the system to act as a web server, make use of firewalld's supported services to enable HTTP and HTTPS traffic to pass through the firewall as required.
To enable HTTP using the command line, issue the following command as root:
~]# firewall-cmd --add-service http
 success
To enable HTTPS using the command line, issue the following command as root:
~]# firewall-cmd --add-service https
 success
Note that these changes will not persist after the next system start. To make permanent changes to the firewall, repeat the commands adding the --permanent option.

13.1.12.1. Checking Network Access for Incoming HTTPS and HTTPS Using the Command Line

To check what services the firewall is configured to allow, using the command line, issue the following command as root:
~]# firewall-cmd --list-all
public (default, active)
  interfaces: em1
  sources: 
  services: dhcpv6-client ssh
output truncated
In this example taken from a default installation, the firewall is enabled but HTTP and HTTPS have not been allowed to pass through.
Once the HTTP and HTTP firewall services are enabled, the services line will appear similar to the following:
services: dhcpv6-client http https ssh
For more information on enabling firewall services, or opening and closing ports with firewalld, see the Red Hat Enterprise Linux 7 Security Guide.

13.1.13. Additional Resources

To learn more about the Apache HTTP Server, see the following resources.

Installed Documentation

  • httpd(8) — The manual page for the httpd service containing the complete list of its command-line options.
  • genkey(1) — The manual page for genkey utility, provided by the crypto-utils package.
  • apachectl(8) — The manual page for the Apache HTTP Server Control Interface.

Installable Documentation

  • http://localhost/manual/ — The official documentation for the Apache HTTP Server with the full description of its directives and available modules. Note that in order to access this documentation, you must have the httpd-manual package installed, and the web server must be running.
    Before accessing the documentation, issue the following commands as root:
    ~]# yum install httpd-manual
    ~]# apachectl graceful

Online Documentation

  • http://httpd.apache.org/ — The official website for the Apache HTTP Server with documentation on all the directives and default modules.
  • http://www.openssl.org/ — The OpenSSL home page containing further documentation, frequently asked questions, links to the mailing lists, and other useful resources.

Chapter 14. Mail Servers

Red Hat Enterprise Linux offers many advanced applications to serve and access email. This chapter describes modern email protocols in use today, and some of the programs designed to send and receive email.

14.1. Email Protocols

Today, email is delivered using a client/server architecture. An email message is created using a mail client program. This program then sends the message to a server. The server then forwards the message to the recipient's email server, where the message is then supplied to the recipient's email client.
To enable this process, a variety of standard network protocols allow different machines, often running different operating systems and using different email programs, to send and receive email.
The following protocols discussed are the most commonly used in the transfer of email.

14.1.1. Mail Transport Protocols

Mail delivery from a client application to the server, and from an originating server to the destination server, is handled by the Simple Mail Transfer Protocol (SMTP).

14.1.1.1. SMTP

The primary purpose of SMTP is to transfer email between mail servers. However, it is critical for email clients as well. To send email, the client sends the message to an outgoing mail server, which in turn contacts the destination mail server for delivery. For this reason, it is necessary to specify an SMTP server when configuring an email client.
Under Red Hat Enterprise Linux, a user can configure an SMTP server on the local machine to handle mail delivery. However, it is also possible to configure remote SMTP servers for outgoing mail.
One important point to make about the SMTP protocol is that it does not require authentication. This allows anyone on the Internet to send email to anyone else or even to large groups of people. It is this characteristic of SMTP that makes junk email or spam possible. Imposing relay restrictions limits random users on the Internet from sending email through your SMTP server, to other servers on the internet. Servers that do not impose such restrictions are called open relay servers.
Red Hat Enterprise Linux 7 provides the Postfix and Sendmail SMTP programs.

14.1.2. Mail Access Protocols

There are two primary protocols used by email client applications to retrieve email from mail servers: the Post Office Protocol (POP) and the Internet Message Access Protocol (IMAP).

14.1.2.1. POP

The default POP server under Red Hat Enterprise Linux is Dovecot and is provided by the dovecot package.

Note

In order to use Dovecot, first ensure the dovecot package is installed on your system by running, as root:
~]# yum install dovecot
For more information on installing packages with Yum, see Section 8.2.4, “Installing Packages”.
When using a POP server, email messages are downloaded by email client applications. By default, most POP email clients are automatically configured to delete the message on the email server after it has been successfully transferred, however this setting usually can be changed.
POP is fully compatible with important Internet messaging standards, such as Multipurpose Internet Mail Extensions (MIME), which allow for email attachments.
POP works best for users who have one system on which to read email. It also works well for users who do not have a persistent connection to the Internet or the network containing the mail server. Unfortunately for those with slow network connections, POP requires client programs upon authentication to download the entire content of each message. This can take a long time if any messages have large attachments.
The most current version of the standard POP protocol is POP3.
There are, however, a variety of lesser-used POP protocol variants:
  • APOPPOP3 with MD5 authentication. An encoded hash of the user's password is sent from the email client to the server rather than sending an unencrypted password.
  • KPOPPOP3 with Kerberos authentication.
  • RPOPPOP3 with RPOP authentication. This uses a per-user ID, similar to a password, to authenticate POP requests. However, this ID is not encrypted, so RPOP is no more secure than standard POP.
For added security, it is possible to use Secure Socket Layer (SSL) encryption for client authentication and data transfer sessions. This can be enabled by using the pop3s service, or by using the stunnel application. For more information on securing email communication, see Section 14.5.1, “Securing Communication”.

14.1.2.2. IMAP

The default IMAP server under Red Hat Enterprise Linux is Dovecot and is provided by the dovecot package. See Section 14.1.2.1, “POP” for information on how to install Dovecot.
When using an IMAP mail server, email messages remain on the server where users can read or delete them. IMAP also allows client applications to create, rename, or delete mail directories on the server to organize and store email.
IMAP is particularly useful for users who access their email using multiple machines. The protocol is also convenient for users connecting to the mail server via a slow connection, because only the email header information is downloaded for messages until opened, saving bandwidth. The user also has the ability to delete messages without viewing or downloading them.
For convenience, IMAP client applications are capable of caching copies of messages locally, so the user can browse previously read messages when not directly connected to the IMAP server.
IMAP, like POP, is fully compatible with important Internet messaging standards, such as MIME, which allow for email attachments.
For added security, it is possible to use SSL encryption for client authentication and data transfer sessions. This can be enabled by using the imaps service, or by using the stunnel program. For more information on securing email communication, see Section 14.5.1, “Securing Communication”.
Other free, as well as commercial, IMAP clients and servers are available, many of which extend the IMAP protocol and provide additional functionality.

14.1.2.3. Dovecot

The imap-login and pop3-login processes which implement the IMAP and POP3 protocols are spawned by the master dovecot daemon included in the dovecot package. The use of IMAP and POP is configured through the /etc/dovecot/dovecot.conf configuration file; by default dovecot runs IMAP and POP3 together with their secure versions using SSL. To configure dovecot to use POP, complete the following steps:
  1. Edit the /etc/dovecot/dovecot.conf configuration file to make sure the protocols variable is uncommented (remove the hash sign (#) at the beginning of the line) and contains the pop3 argument. For example:
    protocols = imap pop3 lmtp
    When the protocols variable is left commented out, dovecot will use the default values as described above.
  2. Make the change operational for the current session by running the following command as root:
    ~]# systemctl restart dovecot
  3. Make the change operational after the next reboot by running the command:
    ~]# systemctl enable dovecot
    Created symlink from /etc/systemd/system/multi-user.target.wants/dovecot.service to /usr/lib/systemd/system/dovecot.service.

    Note

    Please note that dovecot only reports that it started the IMAP server, but also starts the POP3 server.
Unlike SMTP, both IMAP and POP3 require connecting clients to authenticate using a user name and password. By default, passwords for both protocols are passed over the network unencrypted.
To configure SSL on dovecot:
  • Edit the /etc/dovecot/conf.d/10-ssl.conf configuration to make sure the ssl_protocols variable is uncommented and contains the !SSLv2 !SSLv3 arguments:
    ssl_protocols = !SSLv2 !SSLv3
    These values ensure that dovecot avoids SSL versions 2 and also 3, which are both known to be insecure. This is due to the vulnerability described in POODLE: SSLv3 vulnerability (CVE-2014-3566). See Resolution for POODLE SSL 3.0 vulnerability (CVE-2014-3566) in Postfix and Dovecot for details.
  • Edit the /etc/pki/dovecot/dovecot-openssl.cnf configuration file as you prefer. However, in a typical installation, this file does not require modification.
  • Rename, move or delete the files /etc/pki/dovecot/certs/dovecot.pem and /etc/pki/dovecot/private/dovecot.pem.
  • Execute the /usr/libexec/dovecot/mkcert.sh script which creates the dovecot self signed certificates. These certificates are copied in the /etc/pki/dovecot/certs and /etc/pki/dovecot/private directories. To implement the changes, restart dovecot by issuing the following command as root:
    ~]# systemctl restart dovecot
More details on dovecot can be found online at http://www.dovecot.org.

14.2. Email Program Classifications

In general, all email applications fall into at least one of three classifications. Each classification plays a specific role in the process of moving and managing email messages. While most users are only aware of the specific email program they use to receive and send messages, each one is important for ensuring that email arrives at the correct destination.

14.2.1. Mail Transport Agent

A Mail Transport Agent (MTA) transports email messages between hosts using SMTP. A message may involve several MTAs as it moves to its intended destination.
While the delivery of messages between machines may seem rather straightforward, the entire process of deciding if a particular MTA can or should accept a message for delivery is quite complicated. In addition, due to problems from spam, use of a particular MTA is usually restricted by the MTA's configuration or the access configuration for the network on which the MTA resides.
Many modern email client programs can act as an MTA when sending email. However, this action should not be confused with the role of a true MTA. The sole reason email client programs are capable of sending email like an MTA is because the host running the application does not have its own MTA. This is particularly true for email client programs on non-UNIX-based operating systems. However, these client programs only send outbound messages to an MTA they are authorized to use and do not directly deliver the message to the intended recipient's email server.
Since Red Hat Enterprise Linux offers two MTAs, Postfix and Sendmail, email client programs are often not required to act as an MTA. Red Hat Enterprise Linux also includes a special purpose MTA called Fetchmail.
For more information on Postfix, Sendmail, and Fetchmail, see Section 14.3, “Mail Transport Agents”.

14.2.2. Mail Delivery Agent

A Mail Delivery Agent (MDA) is invoked by the MTA to file incoming email in the proper user's mailbox. In many cases, the MDA is actually a Local Delivery Agent (LDA), such as mail or Procmail.
Any program that actually handles a message for delivery to the point where it can be read by an email client application can be considered an MDA. For this reason, some MTAs (such as Sendmail and Postfix) can fill the role of an MDA when they append new email messages to a local user's mail spool file. In general, MDAs do not transport messages between systems nor do they provide a user interface; MDAs distribute and sort messages on the local machine for an email client application to access.

14.2.3. Mail User Agent

A Mail User Agent (MUA) is synonymous with an email client application. An MUA is a program that, at a minimum, allows a user to read and compose email messages. Many MUAs are capable of retrieving messages via the POP or IMAP protocols, setting up mailboxes to store messages, and sending outbound messages to an MTA.
MUAs may be graphical, such as Evolution, or have simple text-based interfaces, such as Mutt.

14.3. Mail Transport Agents

Red Hat Enterprise Linux 7 offers two primary MTAs: Postfix and Sendmail. Postfix is configured as the default MTA and Sendmail is considered deprecated. If required to switch the default MTA to Sendmail, you can either uninstall Postfix or use the following command as root to switch to Sendmail:
~]# alternatives --config mta
You can also use the following command to enable the desired service:
~]# systemctl enable service
Similarly, to disable the service, type the following at a shell prompt:
~]# systemctl disable service
For more information on how to manage system services in Red Hat Enterprise Linux 7, see Chapter 9, Managing Services with systemd.

14.3.1. Postfix

Originally developed at IBM by security expert and programmer Wietse Venema, Postfix is a Sendmail-compatible MTA that is designed to be secure, fast, and easy to configure.
To improve security, Postfix uses a modular design, where small processes with limited privileges are launched by a master daemon. The smaller, less privileged processes perform very specific tasks related to the various stages of mail delivery and run in a changed root environment to limit the effects of attacks.
Configuring Postfix to accept network connections from hosts other than the local computer takes only a few minor changes in its configuration file. Yet for those with more complex needs, Postfix provides a variety of configuration options, as well as third party add-ons that make it a very versatile and full-featured MTA.
The configuration files for Postfix are human readable and support upward of 250 directives. Unlike Sendmail, no macro processing is required for changes to take effect and the majority of the most commonly used options are described in the heavily commented files.

14.3.1.1. The Default Postfix Installation

The Postfix executable is postfix. This daemon launches all related processes needed to handle mail delivery.
Postfix stores its configuration files in the /etc/postfix/ directory. The following is a list of the more commonly used files:
  • access — Used for access control, this file specifies which hosts are allowed to connect to Postfix.
  • main.cf — The global Postfix configuration file. The majority of configuration options are specified in this file.
  • master.cf — Specifies how Postfix interacts with various processes to accomplish mail delivery.
  • transport — Maps email addresses to relay hosts.
The aliases file can be found in the /etc directory. This file is shared between Postfix and Sendmail. It is a configurable list required by the mail protocol that describes user ID aliases.

Important

The default /etc/postfix/main.cf file does not allow Postfix to accept network connections from a host other than the local computer. For instructions on configuring Postfix as a server for other clients, see Section 14.3.1.3, “Basic Postfix Configuration”.
Restart the postfix service after changing any options in the configuration files under the /etc/postfix/ directory in order for those changes to take effect. To do so, run the following command as root:
~]# systemctl restart postfix

14.3.1.2. Upgrading From a Previous Release

The following settings in Red Hat Enterprise Linux 7 are different to previous releases:
  • disable_vrfy_command = no — This is disabled by default, which is different to the default for Sendmail. If changed to yes it can prevent certain email address harvesting methods.
  • allow_percent_hack = yes — This is enabled by default. It allows removing % characters in email addresses. The percent hack is an old workaround that allowed sender-controlled routing of email messages. DNS and mail routing are now much more reliable, but Postfix continues to support the hack. To turn off percent rewriting, set allow_percent_hack to no.
  • smtpd_helo_required = no — This is disabled by default, as it is in Sendmail, because it can prevent some applications from sending mail. It can be changed to yes to require clients to send the HELO or EHLO commands before attempting to send the MAIL, FROM, or ETRN commands.

14.3.1.3. Basic Postfix Configuration

By default, Postfix does not accept network connections from any host other than the local host. Perform the following steps as root to enable mail delivery for other hosts on the network:
  • Edit the /etc/postfix/main.cf file with a text editor, such as vi.
  • Uncomment the mydomain line by removing the hash sign (#), and replace domain.tld with the domain the mail server is servicing, such as example.com.
  • Uncomment the myorigin = $mydomain line.
  • Uncomment the myhostname line, and replace host.domain.tld with the host name for the machine.
  • Uncomment the mydestination = $myhostname, localhost.$mydomain line.
  • Uncomment the mynetworks line, and replace 168.100.189.0/28 with a valid network setting for hosts that can connect to the server.
  • Uncomment the inet_interfaces = all line.
  • Comment the inet_interfaces = localhost line.
  • Restart the postfix service.
Once these steps are complete, the host accepts outside emails for delivery.
Postfix has a large assortment of configuration options. One of the best ways to learn how to configure Postfix is to read the comments within the /etc/postfix/main.cf configuration file. Additional resources including information about Postfix configuration, SpamAssassin integration, or detailed descriptions of the /etc/postfix/main.cf parameters are available online at http://www.postfix.org/.

Important

Due to the vulnerability described in POODLE: SSLv3 vulnerability (CVE-2014-3566), Red Hat recommends disabling SSL and using only TLSv1.1 or TLSv1.2. See Resolution for POODLE SSL 3.0 vulnerability (CVE-2014-3566) in Postfix and Dovecot for details.

14.3.1.4. Using Postfix with LDAP

Postfix can use an LDAP directory as a source for various lookup tables (e.g.: aliases, virtual, canonical, etc.). This allows LDAP to store hierarchical user information and Postfix to only be given the result of LDAP queries when needed. By not storing this information locally, administrators can easily maintain it.
14.3.1.4.1. The /etc/aliases lookup example
The following is a basic example for using LDAP to look up the /etc/aliases file. Make sure your /etc/postfix/main.cf file contains the following:
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
Create a /etc/postfix/ldap-aliases.cf file if you do not have one already and make sure it contains the following:
server_host = ldap.example.com
search_base = dc=example, dc=com
where ldap.example.com, example, and com are parameters that need to be replaced with specification of an existing available LDAP server.

Note

The /etc/postfix/ldap-aliases.cf file can specify various parameters, including parameters that enable LDAP SSL and STARTTLS. For more information, see the ldap_table(5) man page.
For more information on LDAP, see OpenLDAP in the System-Level Authentication Guide.

14.3.2. Sendmail

Sendmail's core purpose, like other MTAs, is to safely transfer email among hosts, usually using the SMTP protocol. Note that Sendmail is considered deprecated and users are encouraged to use Postfix when possible. See Section 14.3.1, “Postfix” for more information.

14.3.2.1. Purpose and Limitations

It is important to be aware of what Sendmail is and what it can do, as opposed to what it is not. In these days of monolithic applications that fulfill multiple roles, Sendmail may seem like the only application needed to run an email server within an organization. Technically, this is true, as Sendmail can spool mail to each users' directory and deliver outbound mail for users. However, most users actually require much more than simple email delivery. Users usually want to interact with their email using an MUA, that uses POP or IMAP, to download their messages to their local machine. Or, they may prefer a Web interface to gain access to their mailbox. These other applications can work in conjunction with Sendmail, but they actually exist for different reasons and can operate separately from one another.
It is beyond the scope of this section to go into all that Sendmail should or could be configured to do. With literally hundreds of different options and rule sets, entire volumes have been dedicated to helping explain everything that can be done and how to fix things that go wrong. See the Section 14.6, “Additional Resources” for a list of Sendmail resources.
This section reviews the files installed with Sendmail by default and reviews basic configuration changes, including how to stop unwanted email (spam) and how to extend Sendmail with the Lightweight Directory Access Protocol (LDAP).

14.3.2.2. The Default Sendmail Installation

In order to use Sendmail, first ensure the sendmail package is installed on your system by running, as root:
~]# yum install sendmail
In order to configure Sendmail, ensure the sendmail-cf package is installed on your system by running, as root:
~]# yum install sendmail-cf
For more information on installing packages with Yum, see Section 8.2.4, “Installing Packages”.
Before using Sendmail, the default MTA has to be switched from Postfix. For more information how to switch the default MTA refer to Section 14.3, “Mail Transport Agents”.
The Sendmail executable is sendmail.
Sendmail's lengthy and detailed configuration file is /etc/mail/sendmail.cf. Avoid editing the sendmail.cf file directly. To make configuration changes to Sendmail, edit the /etc/mail/sendmail.mc file, back up the original /etc/mail/sendmail.cf file, and use the following alternatives to generate a new configuration file:
  • Use the included makefile in /etc/mail/ to create a new /etc/mail/sendmail.cf configuration file:
    ~]# make all -C /etc/mail/
    All other generated files in /etc/mail (db files) will be regenerated if needed. The old makemap commands are still usable. The make command is automatically used whenever you start or restart the sendmail service.
More information on configuring Sendmail can be found in Section 14.3.2.3, “Common Sendmail Configuration Changes”.
Various Sendmail configuration files are installed in the /etc/mail/ directory including:
  • access — Specifies which systems can use Sendmail for outbound email.
  • domaintable — Specifies domain name mapping.
  • local-host-names — Specifies aliases for the host.
  • mailertable — Specifies instructions that override routing for particular domains.
  • virtusertable — Specifies a domain-specific form of aliasing, allowing multiple virtual domains to be hosted on one machine.
Several of the configuration files in the /etc/mail/ directory, such as access, domaintable, mailertable and virtusertable, must actually store their information in database files before Sendmail can use any configuration changes. To include any changes made to these configurations in their database files, run the following commands, as root:
~]# cd /etc/mail/
~]# make all
This will update virtusertable.db, access.db, domaintable.db, mailertable.db, sendmail.cf, and submit.cf.
To update all the database files listed above and to update a custom database file, use a command in the following format:
make name.db all
where name represents the name of the custom database file to be updated.
To update a single database, use a command in the following format:
make name.db
where name.db represents the name of the database file to be updated.
You may also restart the sendmail service for the changes to take effect by running:
~]# systemctl restart sendmail
For example, to have all emails addressed to the example.com domain delivered to bob@other-example.com, add the following line to the virtusertable file:
@example.com bob@other-example.com
To finalize the change, the virtusertable.db file must be updated:
~]# make virtusertable.db all
Using the all option will result in the virtusertable.db and access.db being updated at the same time.

14.3.2.3. Common Sendmail Configuration Changes

When altering the Sendmail configuration file, it is best not to edit an existing file, but to generate an entirely new /etc/mail/sendmail.cf file.

Warning

Before replacing or making any changes to the sendmail.cf file, create a backup copy.
To add the desired functionality to Sendmail, edit the /etc/mail/sendmail.mc file as root. Once you are finished, restart the sendmail service and, if the m4 package is installed, the m4 macro processor will automatically generate a new sendmail.cf configuration file:
~]# systemctl restart sendmail

Important

The default sendmail.cf file does not allow Sendmail to accept network connections from any host other than the local computer. To configure Sendmail as a server for other clients, edit the /etc/mail/sendmail.mc file, and either change the address specified in the Addr= option of the DAEMON_OPTIONS directive from 127.0.0.1 to the IP address of an active network device or comment out the DAEMON_OPTIONS directive all together by placing dnl at the beginning of the line. When finished, regenerate /etc/mail/sendmail.cf by restarting the service:
~]# systemctl restart sendmail
The default configuration in Red Hat Enterprise Linux works for most SMTP-only sites. However, it does not work for UUCP (UNIX-to-UNIX Copy Protocol) sites. If using UUCP mail transfers, the /etc/mail/sendmail.mc file must be reconfigured and a new /etc/mail/sendmail.cf file must be generated.
Consult the /usr/share/sendmail-cf/README file before editing any files in the directories under the /usr/share/sendmail-cf/ directory, as they can affect the future configuration of the /etc/mail/sendmail.cf file.

14.3.2.4. Masquerading

One common Sendmail configuration is to have a single machine act as a mail gateway for all machines on the network. For example, a company may want to have a machine called mail.example.com that handles all of their email and assigns a consistent return address to all outgoing mail.
In this situation, the Sendmail server must masquerade the machine names on the company network so that their return address is user@example.com instead of user@host.example.com.
To do this, add the following lines to /etc/mail/sendmail.mc:
FEATURE(always_add_domain)dnl
FEATURE(`masquerade_entire_domain')dnl
FEATURE(`masquerade_envelope')dnl
FEATURE(`allmasquerade')dnl
MASQUERADE_AS(`example.com.')dnl
MASQUERADE_DOMAIN(`example.com.')dnl
MASQUERADE_AS(example.com)dnl
After generating a new sendmail.cf file using the m4 macro processor, this configuration makes all mail from inside the network appear as if it were sent from example.com.
Note that administrators of mail servers, DNS and DHCP servers, as well as any provisioning applications, should agree on the host name format used in an organization. See the Red Hat Enterprise Linux 7 Networking Guide for more information on recommended naming practices.

14.3.2.5. Stopping Spam

Email spam can be defined as unnecessary and unwanted email received by a user who never requested the communication. It is a disruptive, costly, and widespread abuse of Internet communication standards.
Sendmail makes it relatively easy to block new spamming techniques being employed to send junk email. It even blocks many of the more usual spamming methods by default. Main anti-spam features available in sendmail are header checks, relaying denial (default from version 8.9), access database and sender information checks.
For example, forwarding of SMTP messages, also called relaying, has been disabled by default since Sendmail version 8.9. Before this change occurred, Sendmail directed the mail host (x.edu) to accept messages from one party (y.com) and sent them to a different party (z.net). Now, however, Sendmail must be configured to permit any domain to relay mail through the server. To configure relay domains, edit the /etc/mail/relay-domains file and restart Sendmail
~]# systemctl restart sendmail
However users can also be sent spam from from servers on the Internet. In these instances, Sendmail's access control features available through the /etc/mail/access file can be used to prevent connections from unwanted hosts. The following example illustrates how this file can be used to both block and specifically allow access to the Sendmail server:
badspammer.com ERROR:550 "Go away and do not spam us anymore" tux.badspammer.com OK 10.0 RELAY
This example shows that any email sent from badspammer.com is blocked with a 550 RFC-821 compliant error code, with a message sent back. Email sent from the tux.badspammer.com sub-domain, is accepted. The last line shows that any email sent from the 10.0.*.* network can be relayed through the mail server.
Because the /etc/mail/access.db file is a database, use the makemap command to update any changes. Do this using the following command as root:
~]# makemap hash /etc/mail/access < /etc/mail/access
Message header analysis allows you to reject mail based on header contents. SMTP servers store information about an email's journey in the message header. As the message travels from one MTA to another, each puts in a Received header above all the other Received headers. It is important to note that this information may be altered by spammers.
The above examples only represent a small part of what Sendmail can do in terms of allowing or blocking access. See the /usr/share/sendmail-cf/README file for more information and examples.
Since Sendmail calls the Procmail MDA when delivering mail, it is also possible to use a spam filtering program, such as SpamAssassin, to identify and file spam for users. See Section 14.4.2.6, “Spam Filters” for more information about using SpamAssassin.

14.3.2.6. Using Sendmail with LDAP

Using LDAP is a very quick and powerful way to find specific information about a particular user from a much larger group. For example, an LDAP server can be used to look up a particular email address from a common corporate directory by the user's last name. In this kind of implementation, LDAP is largely separate from Sendmail, with LDAP storing the hierarchical user information and Sendmail only being given the result of LDAP queries in pre-addressed email messages.
However, Sendmail supports a much greater integration with LDAP, where it uses LDAP to replace separately maintained files, such as /etc/aliases and /etc/mail/virtusertables, on different mail servers that work together to support a medium- to enterprise-level organization. In short, LDAP abstracts the mail routing level from Sendmail and its separate configuration files to a powerful LDAP cluster that can be leveraged by many different applications.
The current version of Sendmail contains support for LDAP. To extend the Sendmail server using LDAP, first get an LDAP server, such as OpenLDAP, running and properly configured. Then edit the /etc/mail/sendmail.mc to include the following:
LDAPROUTE_DOMAIN('yourdomain.com')dnl
FEATURE('ldap_routing')dnl

Note

This is only for a very basic configuration of Sendmail with LDAP. The configuration can differ greatly from this depending on the implementation of LDAP, especially when configuring several Sendmail machines to use a common LDAP server.
Consult /usr/share/sendmail-cf/README for detailed LDAP routing configuration instructions and examples.
Next, recreate the /etc/mail/sendmail.cf file by running the m4 macro processor and again restarting Sendmail. See Section 14.3.2.3, “Common Sendmail Configuration Changes” for instructions.
For more information on LDAP, see OpenLDAP in the System-Level Authentication Guide.

14.3.3. Fetchmail

Fetchmail is an MTA which retrieves email from remote servers and delivers it to the local MTA. Many users appreciate the ability to separate the process of downloading their messages located on a remote server from the process of reading and organizing their email in an MUA. Designed with the needs of dial-up users in mind, Fetchmail connects and quickly downloads all of the email messages to the mail spool file using any number of protocols, including POP3 and IMAP. It can even forward email messages to an SMTP server, if necessary.

Note

In order to use Fetchmail, first ensure the fetchmail package is installed on your system by running, as root:
~]# yum install fetchmail
For more information on installing packages with Yum, see Section 8.2.4, “Installing Packages”.
Fetchmail is configured for each user through the use of a .fetchmailrc file in the user's home directory. If it does not already exist, create the .fetchmailrc file in your home directory
Using preferences in the .fetchmailrc file, Fetchmail checks for email on a remote server and downloads it. It then delivers it to port 25 on the local machine, using the local MTA to place the email in the correct user's spool file. If Procmail is available, it is launched to filter the email and place it in a mailbox so that it can be read by an MUA.

14.3.3.1. Fetchmail Configuration Options

Although it is possible to pass all necessary options on the command line to check for email on a remote server when executing Fetchmail, using a .fetchmailrc file is much easier. Place any desired configuration options in the .fetchmailrc file for those options to be used each time the fetchmail command is issued. It is possible to override these at the time Fetchmail is run by specifying that option on the command line.
A user's .fetchmailrc file contains three classes of configuration options:
  • global options — Gives Fetchmail instructions that control the operation of the program or provide settings for every connection that checks for email.
  • server options — Specifies necessary information about the server being polled, such as the host name, as well as preferences for specific email servers, such as the port to check or number of seconds to wait before timing out. These options affect every user using that server.
  • user options — Contains information, such as user name and password, necessary to authenticate and check for email using a specified email server.
Global options appear at the top of the .fetchmailrc file, followed by one or more server options, each of which designate a different email server that Fetchmail should check. User options follow server options for each user account checking that email server. Like server options, multiple user options may be specified for use with a particular server as well as to check multiple email accounts on the same server.
Server options are called into service in the .fetchmailrc file by the use of a special option verb, poll or skip, that precedes any of the server information. The poll action tells Fetchmail to use this server option when it is run, which checks for email using the specified user options. Any server options after a skip action, however, are not checked unless this server's host name is specified when Fetchmail is invoked. The skip option is useful when testing configurations in the .fetchmailrc file because it only checks skipped servers when specifically invoked, and does not affect any currently working configurations.
The following is an example of a .fetchmailrc file:
set postmaster "user1"
set bouncemail

poll pop.domain.com proto pop3
    user 'user1' there with password 'secret' is user1 here

poll mail.domain2.com
    user 'user5' there with password 'secret2' is user1 here
    user 'user7' there with password 'secret3' is user1 here
In this example, the global options specify that the user is sent email as a last resort (postmaster option) and all email errors are sent to the postmaster instead of the sender (bouncemail option). The set action tells Fetchmail that this line contains a global option. Then, two email servers are specified, one set to check using POP3, the other for trying various protocols to find one that works. Two users are checked using the second server option, but all email found for any user is sent to user1's mail spool. This allows multiple mailboxes to be checked on multiple servers, while appearing in a single MUA inbox. Each user's specific information begins with the user action.

Note

Users are not required to place their password in the .fetchmailrc file. Omitting the with password 'password' section causes Fetchmail to ask for a password when it is launched.
Fetchmail has numerous global, server, and local options. Many of these options are rarely used or only apply to very specific situations. The fetchmail man page explains each option in detail, but the most common ones are listed in the following three sections.

14.3.3.2. Global Options

Each global option should be placed on a single line after a set action.
  • daemon seconds — Specifies daemon-mode, where Fetchmail stays in the background. Replace seconds with the number of seconds Fetchmail is to wait before polling the server.
  • postmaster — Specifies a local user to send mail to in case of delivery problems.
  • syslog — Specifies the log file for errors and status messages. By default, this is /var/log/maillog.

14.3.3.3. Server Options

Server options must be placed on their own line in .fetchmailrc after a poll or skip action.
  • auth auth-type — Replace auth-type with the type of authentication to be used. By default, password authentication is used, but some protocols support other types of authentication, including kerberos_v5, kerberos_v4, and ssh. If the any authentication type is used, Fetchmail first tries methods that do not require a password, then methods that mask the password, and finally attempts to send the password unencrypted to authenticate to the server.
  • interval number — Polls the specified server every number of times that it checks for email on all configured servers. This option is generally used for email servers where the user rarely receives messages.
  • port port-number — Replace port-number with the port number. This value overrides the default port number for the specified protocol.
  • proto protocol — Replace protocol with the protocol, such as pop3 or imap, to use when checking for messages on the server.
  • timeout seconds — Replace seconds with the number of seconds of server inactivity after which Fetchmail gives up on a connection attempt. If this value is not set, a default of 300 seconds is used.

14.3.3.4. User Options

User options may be placed on their own lines beneath a server option or on the same line as the server option. In either case, the defined options must follow the user option (defined below).
  • fetchall — Orders Fetchmail to download all messages in the queue, including messages that have already been viewed. By default, Fetchmail only pulls down new messages.
  • fetchlimit number — Replace number with the number of messages to be retrieved before stopping.
  • flush — Deletes all previously viewed messages in the queue before retrieving new messages.
  • limit max-number-bytes — Replace max-number-bytes with the maximum size in bytes that messages are allowed to be when retrieved by Fetchmail. This option is useful with slow network links, when a large message takes too long to download.
  • password 'password' — Replace password with the user's password.
  • preconnect "command" — Replace command with a command to be executed before retrieving messages for the user.
  • postconnect "command" — Replace command with a command to be executed after retrieving messages for the user.
  • ssl — Activates SSL encryption. At the time of writing, the default action is to use the best available from SSL2, SSL3, SSL23, TLS1, TLS1.1 and TLS1.2. Note that SSL2 is considered obsolete and due to the POODLE: SSLv3 vulnerability (CVE-2014-3566), SSLv3 should not be used. However there is no way to force the use of TLS1 or newer, therefore ensure the mail server being connected to is configured not to use SSLv2 and SSLv3. Use stunnel where the server cannot be configured not to use SSLv2 and SSLv3.
  • sslproto — Defines allowed SSL or TLS protocols. Possible values are SSL2, SSL3, SSL23, and TLS1. The default value, if sslproto is omitted, unset, or set to an invalid value, is SSL23. The default action is to use the best from SSLv2, SSLv3, TLSv1, TLS1.1 and TLS1.2. Note that setting any other value for SSL or TLS will disable all the other protocols. Due to the POODLE: SSLv3 vulnerability (CVE-2014-3566), it is recommend to omit this option, or set it to SSLv23, and configure the corresponding mail server not to use SSLv2 and SSLv3. Use stunnel where the server cannot be configured not to use SSLv2 and SSLv3.
  • user "username" — Replace username with the user name used by Fetchmail to retrieve messages. This option must precede all other user options.

14.3.3.5. Fetchmail Command Options

Most Fetchmail options used on the command line when executing the fetchmail command mirror the .fetchmailrc configuration options. In this way, Fetchmail may be used with or without a configuration file. These options are not used on the command line by most users because it is easier to leave them in the .fetchmailrc file.
There may be times when it is desirable to run the fetchmail command with other options for a particular purpose. It is possible to issue command options to temporarily override a .fetchmailrc setting that is causing an error, as any options specified at the command line override configuration file options.

14.3.3.6. Informational or Debugging Options

Certain options used after the fetchmail command can supply important information.
  • --configdump — Displays every possible option based on information from .fetchmailrc and Fetchmail defaults. No email is retrieved for any users when using this option.
  • -s — Executes Fetchmail in silent mode, preventing any messages, other than errors, from appearing after the fetchmail command.
  • -v — Executes Fetchmail in verbose mode, displaying every communication between Fetchmail and remote email servers.
  • -V — Displays detailed version information, lists its global options, and shows settings to be used with each user, including the email protocol and authentication method. No email is retrieved for any users when using this option.

14.3.3.7. Special Options

These options are occasionally useful for overriding defaults often found in the .fetchmailrc file.
  • -a — Fetchmail downloads all messages from the remote email server, whether new or previously viewed. By default, Fetchmail only downloads new messages.
  • -k — Fetchmail leaves the messages on the remote email server after downloading them. This option overrides the default behavior of deleting messages after downloading them.
  • -l max-number-bytes — Fetchmail does not download any messages over a particular size and leaves them on the remote email server.
  • --quit — Quits the Fetchmail daemon process.
More commands and .fetchmailrc options can be found in the fetchmail man page.

14.3.4. Mail Transport Agent (MTA) Configuration

A Mail Transport Agent (MTA) is essential for sending email. A Mail User Agent (MUA) such as Evolution or Mutt, is used to read and compose email. When a user sends an email from an MUA, the message is handed off to the MTA, which sends the message through a series of MTAs until it reaches its destination.
Even if a user does not plan to send email from the system, some automated tasks or system programs might use the mail command to send email containing log messages to the root user of the local system.
Red Hat Enterprise Linux 7 provides two MTAs: Postfix and Sendmail. If both are installed, Postfix is the default MTA. Note that Sendmail is considered deprecated in Red Hat Enterprise Linux 7.

14.4. Mail Delivery Agents

Red Hat Enterprise Linux includes two primary MDAs, Procmail and mail. Both of the applications are considered LDAs and both move email from the MTA's spool file into the user's mailbox. However, Procmail provides a robust filtering system.
This section details only Procmail. For information on the mail command, consult its man page (man mail).
Procmail delivers and filters email as it is placed in the mail spool file of the localhost. It is powerful, gentle on system resources, and widely used. Procmail can play a critical role in delivering email to be read by email client applications.
Procmail can be invoked in several different ways. Whenever an MTA places an email into the mail spool file, Procmail is launched. Procmail then filters and files the email for the MUA and quits. Alternatively, the MUA can be configured to execute Procmail any time a message is received so that messages are moved into their correct mailboxes. By default, the presence of /etc/procmailrc or of a ~/.procmailrc file (also called an rc file) in the user's home directory invokes Procmail whenever an MTA receives a new message.
By default, no system-wide rc files exist in the /etc directory and no .procmailrc files exist in any user's home directory. Therefore, to use Procmail, each user must construct a .procmailrc file with specific environment variables and rules.
Whether Procmail acts upon an email message depends upon whether the message matches a specified set of conditions or recipes in the rc file. If a message matches a recipe, then the email is placed in a specified file, is deleted, or is otherwise processed.
When Procmail starts, it reads the email message and separates the body from the header information. Next, Procmail looks for a /etc/procmailrc file and rc files in the /etc/procmailrcs/ directory for default, system-wide, Procmail environmental variables and recipes. Procmail then searches for a .procmailrc file in the user's home directory. Many users also create additional rc files for Procmail that are referred to within the .procmailrc file in their home directory.

14.4.1. Procmail Configuration

The Procmail configuration file contains important environmental variables. These variables specify things such as which messages to sort and what to do with the messages that do not match any recipes.
These environmental variables usually appear at the beginning of the ~/.procmailrc file in the following format:
env-variable="value"
In this example, env-variable is the name of the variable and value defines the variable.
There are many environment variables not used by most Procmail users and many of the more important environment variables are already defined by a default value. Most of the time, the following variables are used:
  • DEFAULT — Sets the default mailbox where messages that do not match any recipes are placed.
    The default DEFAULT value is the same as $ORGMAIL.
  • INCLUDERC — Specifies additional rc files containing more recipes for messages to be checked against. This breaks up the Procmail recipe lists into individual files that fulfill different roles, such as blocking spam and managing email lists, that can then be turned off or on by using comment characters in the user's ~/.procmailrc file.
    For example, lines in a user's ~/.procmailrc file may look like this:
    MAILDIR=$HOME/Msgs
    INCLUDERC=$MAILDIR/lists.rc
    INCLUDERC=$MAILDIR/spam.rc
    To turn off Procmail filtering of email lists but leaving spam control in place, comment out the first INCLUDERC line with a hash sign (#). Note that it uses paths relative to the current directory.
  • LOCKSLEEP — Sets the amount of time, in seconds, between attempts by Procmail to use a particular lockfile. The default is 8 seconds.
  • LOCKTIMEOUT — Sets the amount of time, in seconds, that must pass after a lockfile was last modified before Procmail assumes that the lockfile is old and can be deleted. The default is 1024 seconds.
  • LOGFILE — The file to which any Procmail information or error messages are written.
  • MAILDIR — Sets the current working directory for Procmail. If set, all other Procmail paths are relative to this directory.
  • ORGMAIL — Specifies the original mailbox, or another place to put the messages if they cannot be placed in the default or recipe-required location.
    By default, a value of /var/spool/mail/$LOGNAME is used.
  • SUSPEND — Sets the amount of time, in seconds, that Procmail pauses if a necessary resource, such as swap space, is not available.
  • SWITCHRC — Allows a user to specify an external file containing additional Procmail recipes, much like the INCLUDERC option, except that recipe checking is actually stopped on the referring configuration file and only the recipes on the SWITCHRC-specified file are used.
  • VERBOSE — Causes Procmail to log more information. This option is useful for debugging.
Other important environmental variables are pulled from the shell, such as LOGNAME, the login name; HOME, the location of the home directory; and SHELL, the default shell.
A comprehensive explanation of all environments variables, and their default values, is available in the procmailrc man page.

14.4.2. Procmail Recipes

New users often find the construction of recipes the most difficult part of learning to use Procmail. This difficulty is often attributed to recipes matching messages by using regular expressions which are used to specify qualifications for string matching. However, regular expressions are not very difficult to construct and even less difficult to understand when read. Additionally, the consistency of the way Procmail recipes are written, regardless of regular expressions, makes it easy to learn by example. To see example Procmail recipes, see Section 14.4.2.5, “Recipe Examples”.
Procmail recipes take the following form:
:0 [flags] [: lockfile-name ]
* [ condition_1_special-condition-character condition_1_regular_expression ]
* [ condition_2_special-condition-character condition-2_regular_expression ]
* [ condition_N_special-condition-character condition-N_regular_expression ]
        special-action-character
        action-to-perform
The first two characters in a Procmail recipe are a colon and a zero. Various flags can be placed after the zero to control how Procmail processes the recipe. A colon after the flags section specifies that a lockfile is created for this message. If a lockfile is created, the name can be specified by replacing lockfile-name.
A recipe can contain several conditions to match against the message. If it has no conditions, every message matches the recipe. Regular expressions are placed in some conditions to facilitate message matching. If multiple conditions are used, they must all match for the action to be performed. Conditions are checked based on the flags set in the recipe's first line. Optional special characters placed after the asterisk character (*) can further control the condition.
The action-to-perform argument specifies the action taken when the message matches one of the conditions. There can only be one action per recipe. In many cases, the name of a mailbox is used here to direct matching messages into that file, effectively sorting the email. Special action characters may also be used before the action is specified. See Section 14.4.2.4, “Special Conditions and Actions” for more information.

14.4.2.1. Delivering vs. Non-Delivering Recipes

The action used if the recipe matches a particular message determines whether it is considered a delivering or non-delivering recipe. A delivering recipe contains an action that writes the message to a file, sends the message to another program, or forwards the message to another email address. A non-delivering recipe covers any other actions, such as a nesting block. A nesting block is a set of actions, contained in braces { }, that are performed on messages which match the recipe's conditions. Nesting blocks can be nested inside one another, providing greater control for identifying and performing actions on messages.
When messages match a delivering recipe, Procmail performs the specified action and stops comparing the message against any other recipes. Messages that match non-delivering recipes continue to be compared against other recipes.

14.4.2.2. Flags

Flags are essential to determine how or if a recipe's conditions are compared to a message. The egrep utility is used internally for matching of the conditions. The following flags are commonly used:
  • A — Specifies that this recipe is only used if the previous recipe without an A or a flag also matched this message.
  • a — Specifies that this recipe is only used if the previous recipe with an A or a flag also matched this message and was successfully completed.
  • B — Parses the body of the message and looks for matching conditions.
  • b — Uses the body in any resulting action, such as writing the message to a file or forwarding it. This is the default behavior.
  • c — Generates a carbon copy of the email. This is useful with delivering recipes, since the required action can be performed on the message and a copy of the message can continue being processed in the rc files.
  • D — Makes the egrep comparison case-sensitive. By default, the comparison process is not case-sensitive.
  • E — While similar to the A flag, the conditions in the recipe are only compared to the message if the immediately preceding recipe without an E flag did not match. This is comparable to an else action.
  • e — The recipe is compared to the message only if the action specified in the immediately preceding recipe fails.
  • f — Uses the pipe as a filter.
  • H — Parses the header of the message and looks for matching conditions. This is the default behavior.
  • h — Uses the header in a resulting action. This is the default behavior.
  • w — Tells Procmail to wait for the specified filter or program to finish, and reports whether or not it was successful before considering the message filtered.
  • W — Is identical to w except that "Program failure" messages are suppressed.
For a detailed list of additional flags, see the procmailrc man page.

14.4.2.3. Specifying a Local Lockfile

Lockfiles are very useful with Procmail to ensure that more than one process does not try to alter a message simultaneously. Specify a local lockfile by placing a colon (:) after any flags on a recipe's first line. This creates a local lockfile based on the destination file name plus whatever has been set in the LOCKEXT global environment variable.
Alternatively, specify the name of the local lockfile to be used with this recipe after the colon.

14.4.2.4. Special Conditions and Actions

Special characters used before Procmail recipe conditions and actions change the way they are interpreted.
The following characters may be used after the asterisk character (*) at the beginning of a recipe's condition line:
  • ! — In the condition line, this character inverts the condition, causing a match to occur only if the condition does not match the message.
  • < — Checks if the message is under a specified number of bytes.
  • > — Checks if the message is over a specified number of bytes.
The following characters are used to perform special actions:
  • ! — In the action line, this character tells Procmail to forward the message to the specified email addresses.
  • $ — Refers to a variable set earlier in the rc file. This is often used to set a common mailbox that is referred to by various recipes.
  • | — Starts a specified program to process the message.
  • { and } — Constructs a nesting block, used to contain additional recipes to apply to matching messages.
If no special character is used at the beginning of the action line, Procmail assumes that the action line is specifying the mailbox in which to write the message.

14.4.2.5. Recipe Examples

Procmail is an extremely flexible program, but as a result of this flexibility, composing Procmail recipes from scratch can be difficult for new users.
The best way to develop the skills to build Procmail recipe conditions stems from a strong understanding of regular expressions combined with looking at many examples built by others. A thorough explanation of regular expressions is beyond the scope of this section. The structure of Procmail recipes and useful sample Procmail recipes can be found at various places on the Internet. The proper use and adaptation of regular expressions can be derived by viewing these recipe examples. In addition, introductory information about basic regular expression rules can be found in the grep(1) man page.
The following simple examples demonstrate the basic structure of Procmail recipes and can provide the foundation for more intricate constructions.
A basic recipe may not even contain conditions, as is illustrated in the following example:
:0:
new-mail.spool
The first line specifies that a local lockfile is to be created but does not specify a name, so Procmail uses the destination file name and appends the value specified in the LOCKEXT environment variable. No condition is specified, so every message matches this recipe and is placed in the single spool file called new-mail.spool, located within the directory specified by the MAILDIR environment variable. An MUA can then view messages in this file.
A basic recipe, such as this, can be placed at the end of all rc files to direct messages to a default location.
The following example matched messages from a specific email address and throws them away.
:0
* ^From: spammer@domain.com
/dev/null
With this example, any messages sent by spammer@domain.com are sent to the /dev/null device, deleting them.

Warning

Be certain that rules are working as intended before sending messages to /dev/null for permanent deletion. If a recipe inadvertently catches unintended messages, and those messages disappear, it becomes difficult to troubleshoot the rule.
A better solution is to point the recipe's action to a special mailbox, which can be checked from time to time to look for false positives. Once satisfied that no messages are accidentally being matched, delete the mailbox and direct the action to send the messages to /dev/null.
The following recipe grabs email sent from a particular mailing list and places it in a specified folder.
:0:
* ^(From|Cc|To).*tux-lug
tuxlug
Any messages sent from the tux-lug@domain.com mailing list are placed in the tuxlug mailbox automatically for the MUA. Note that the condition in this example matches the message if it has the mailing list's email address on the From, Cc, or To lines.
Consult the many Procmail online resources available in Section 14.6, “Additional Resources” for more detailed and powerful recipes.

14.4.2.6. Spam Filters

Because it is called by Sendmail, Postfix, and Fetchmail upon receiving new emails, Procmail can be used as a powerful tool for combating spam.
This is particularly true when Procmail is used in conjunction with SpamAssassin. When used together, these two applications can quickly identify spam emails, and sort or destroy them.
SpamAssassin uses header analysis, text analysis, blacklists, a spam-tracking database, and self-learning Bayesian spam analysis to quickly and accurately identify and tag spam.

Note

In order to use SpamAssassin, first ensure the spamassassin package is installed on your system by running, as root:
~]# yum install spamassassin
For more information on installing packages with Yum, see Section 8.2.4, “Installing Packages”.
The easiest way for a local user to use SpamAssassin is to place the following line near the top of the ~/.procmailrc file:
INCLUDERC=/etc/mail/spamassassin/spamassassin-default.rc
The /etc/mail/spamassassin/spamassassin-default.rc contains a simple Procmail rule that activates SpamAssassin for all incoming email. If an email is determined to be spam, it is tagged in the header as such and the title is prepended with the following pattern:
*****SPAM*****
The message body of the email is also prepended with a running tally of what elements caused it to be diagnosed as spam.
To file email tagged as spam, a rule similar to the following can be used:
:0 Hw * ^X-Spam-Status: Yes spam
This rule files all email tagged in the header as spam into a mailbox called spam.
Since SpamAssassin is a Perl script, it may be necessary on busy servers to use the binary SpamAssassin daemon (spamd) and the client application (spamc). Configuring SpamAssassin this way, however, requires root access to the host.
To start the spamd daemon, type the following command:
~]# systemctl start spamassassin
To start the SpamAssassin daemon when the system is booted, run:
systemctl enable spamassassin.service
See Chapter 9, Managing Services with systemd for more information about starting and stopping services.
To configure Procmail to use the SpamAssassin client application instead of the Perl script, place the following line near the top of the ~/.procmailrc file. For a system-wide configuration, place it in /etc/procmailrc:
INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc

14.5. Mail User Agents

Red Hat Enterprise Linux offers a variety of email programs, both, graphical email client programs, such as Evolution, and text-based email programs such as mutt.
The remainder of this section focuses on securing communication between a client and a server.

14.5.1. Securing Communication

Popular MUAs included with Red Hat Enterprise Linux, such as Evolution and Mutt offer SSL-encrypted email sessions.
Like any other service that flows over a network unencrypted, important email information, such as user names, passwords, and entire messages, may be intercepted and viewed by users on the network. Additionally, since the standard POP and IMAP protocols pass authentication information unencrypted, it is possible for an attacker to gain access to user accounts by collecting user names and passwords as they are passed over the network.

14.5.1.1. Secure Email Clients

Most Linux MUAs designed to check email on remote servers support SSL encryption. To use SSL when retrieving email, it must be enabled on both the email client and the server.
SSL is easy to enable on the client-side, often done with the click of a button in the MUA's configuration window or via an option in the MUA's configuration file. Secure IMAP and POP have known port numbers (993 and 995, respectively) that the MUA uses to authenticate and download messages.

14.5.1.2. Securing Email Client Communications

Offering SSL encryption to IMAP and POP users on the email server is a simple matter.
First, create an SSL certificate. This can be done in two ways: by applying to a Certificate Authority (CA) for an SSL certificate or by creating a self-signed certificate.

Warning

Self-signed certificates should be used for testing purposes only. Any server used in a production environment should use an SSL certificate signed by a CA.
To create a self-signed SSL certificate for IMAP or POP, change to the /etc/pki/dovecot/ directory, edit the certificate parameters in the /etc/pki/dovecot/dovecot-openssl.cnf configuration file as you prefer, and type the following commands, as root:
dovecot]# rm -f certs/dovecot.pem private/dovecot.pem
dovecot]# /usr/libexec/dovecot/mkcert.sh
Once finished, make sure you have the following configurations in your /etc/dovecot/conf.d/10-ssl.conf file:
ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
ssl_key = </etc/pki/dovecot/private/dovecot.pem
Issue the following command to restart the dovecot daemon:
~]# systemctl restart dovecot
Alternatively, the stunnel command can be used as an encryption wrapper around the standard, non-secure connections to IMAP or POP services.
The stunnel utility uses external OpenSSL libraries included with Red Hat Enterprise Linux to provide strong cryptography and to protect the network connections. It is recommended to apply to a CA to obtain an SSL certificate, but it is also possible to create a self-signed certificate.
See Using stunnel in the Red Hat Enterprise Linux 7 Security Guide for instructions on how to install stunnel and create its basic configuration. To configure stunnel as a wrapper for IMAPS and POP3S, add the following lines to the /etc/stunnel/stunnel.conf configuration file:
[pop3s]
accept  = 995
connect = 110

[imaps]
accept  = 993
connect = 143
The Security Guide also explains how to start and stop stunnel. Once you start it, it is possible to use an IMAP or a POP email client and connect to the email server using SSL encryption.

14.6. Additional Resources

The following is a list of additional documentation about email applications.

14.6.1. Installed Documentation

  • Information on configuring Sendmail is included with the sendmail and sendmail-cf packages.
    • /usr/share/sendmail-cf/README — Contains information on the m4 macro processor, file locations for Sendmail, supported mailers, how to access enhanced features, and more.
    In addition, the sendmail and aliases man pages contain helpful information covering various Sendmail options and the proper configuration of the Sendmail /etc/mail/aliases file.
  • /usr/share/doc/postfix-version-number/ — Contains a large amount of information on how to configure Postfix. Replace version-number with the version number of Postfix.
  • /usr/share/doc/fetchmail-version-number/ — Contains a full list of Fetchmail features in the FEATURES file and an introductory FAQ document. Replace version-number with the version number of Fetchmail.
  • /usr/share/doc/procmail-version-number/ — Contains a README file that provides an overview of Procmail, a FEATURES file that explores every program feature, and an FAQ file with answers to many common configuration questions. Replace version-number with the version number of Procmail.
    When learning how Procmail works and creating new recipes, the following Procmail man pages are invaluable:
    • procmail — Provides an overview of how Procmail works and the steps involved with filtering email.
    • procmailrc — Explains the rc file format used to construct recipes.
    • procmailex — Gives a number of useful, real-world examples of Procmail recipes.
    • procmailsc — Explains the weighted scoring technique used by Procmail to match a particular recipe to a message.
    • /usr/share/doc/spamassassin-version-number/ — Contains a large amount of information pertaining to SpamAssassin. Replace version-number with the version number of the spamassassin package.

14.6.2. Online Documentation

Chapter 15. File and Print Servers

This chapter guides you through the installation and configuration of Samba, an open source implementation of the Server Message Block (SMB) and common Internet file system (CIFS) protocol, and vsftpd, the primary FTP server shipped with Red Hat Enterprise Linux. Additionally, it explains how to use the Print Settings tool to configure printers.

15.1. Samba

Samba is the standard open source Windows interoperability suite of programs for Linux. It implements the server message block (SMB) protocol. SMB allows Microsoft Windows®, Linux, UNIX, and other operating systems to access files and printers shared from servers that support this protocol. Samba's use of SMB allows it to appear as a Windows server to Windows clients.

Note

In order to use Samba, first ensure the samba package is installed on your system by running, as root:
~]# yum install samba
For more information on installing packages with Yum, see Section 8.2.4, “Installing Packages”.

15.1.1. Introduction to Samba

Samba is an important component to seamlessly integrate Linux Servers and Desktops into Active Directory (AD) environments. It can function both as a domain controller (NT4-style) or as a regular domain member (AD or NT4-style).

What Samba can do:

  • Serve directory trees and printers to Linux, UNIX, and Windows clients
  • Assist in network browsing (with NetBIOS)
  • Authenticate Windows domain logins
  • Provide Windows Internet Name Service (WINS) name server resolution
  • Act as a Windows NT®-style Primary Domain Controller (PDC)
  • Act as a Backup Domain Controller (BDC) for a Samba-based PDC
  • Act as an Active Directory domain member server
  • Join a Windows NT/2000/2003/2008 PDC/Windows Server 2012

What Samba cannot do:

  • Act as a BDC for a Windows PDC (and vice versa)
  • Act as an Active Directory domain controller

15.1.3. Connecting to an SMB Share

15.1.3.1. Connecting to an SMB Share Using the Nautilus File Manager

You can use the GNOME Nautilus file manager to manually browse the network or to directly connect to a server message block (SMB) share.

Browsing the SMB Network Neighborhood

To browse the network and connect to an SMB share:
  1. Select PlacesBrowse Network from the GNOME panel.
  2. Double-click Windows Network to display the available domains and work groups.
  3. Double-click the domain or work group name to display the hosts within this domain or work group.
    Domains and Work Groups Browsing in Nautilus

    Figure 15.1. Domains and Work Groups Browsing in Nautilus

  4. Double-click a host entry to display the SMB shares.
    SMB Hosts in Nautilus

    Figure 15.2. SMB Hosts in Nautilus

    If the server requires authentication, Nautilus displays a dialog to enter the user name and password.

Directly connecting to an SMB Host or Share

If you know the host name of the SMB server and optionally the share name, you can enter it directly to connect to the share:
  1. Open a Nautilus window. For example, select PlacesBrowse Network from the GNOME panel.
  2. Press the Ctrl+L combination to enable the editable URL bar.
  3. Enter smb://host_name into the URL bar and press Enter to list all SMB shares on this host. Alternatively, enter smb://host_name/share_name to directly access a share.
    For example, to access the Demo-Share share on the SMB-Server host:
    Entering an SMB URL in Nautilus

    Figure 15.3. Entering an SMB URL in Nautilus

    If the server requires authentication, Nautilus displays a dialog to enter the user name and password.

15.1.3.2. Connecting to an SMB Share Using smbclient

The smbclient utility enables you to connect to an SMB share and perform operations, similar to an FTP client.
  1. For example, to connect to Demo_Share share on the SMB-Server host and authenticate using the administrator user name, enter:
    # smbclient //SMB-Server/Demo_Share -Uadministrator
  2. After you successfully logged in, enter help to display a list of available commands:
    smb:\> help
    For example, to change into the Example directory, enter:
    smb:\> cd Example
  3. To disconnect, enter:
    smb:\> exit

15.1.4. Mounting the Share

Sometimes it is useful to mount a Samba share to a directory so that the files in the directory can be treated as if they are part of the local file system.
To mount a Samba share to a directory, create a directory to mount it to (if it does not already exist), and execute the following command as root:
mount -t cifs //servername/sharename /mnt/point/ -o username=username,password=password
This command mounts sharename from servername in the local directory /mnt/point/.
For more information about mounting a samba share, see the mount.cifs(8) manual page.

Note

The mount.cifs utility is a separate RPM (independent from Samba). In order to use mount.cifs, first ensure the cifs-utils package is installed on your system by running, as root:
~]# yum install cifs-utils
For more information on installing packages with Yum, see Section 8.2.4, “Installing Packages”.
Note that the cifs-utils package also contains the cifs.upcall binary called by the kernel in order to perform kerberized CIFS mounts. For more information on cifs.upcall, see the cifs.upcall(8) manual page.

Warning

Some CIFS servers require plain text passwords for authentication. Support for plain text password authentication can be enabled using the following command as root:
~]# echo 0x37 > /proc/fs/cifs/SecurityFlags
WARNING: This operation can expose passwords by removing password encryption.

15.1.5. Configuring a Samba Server

The default configuration file (/etc/samba/smb.conf) allows users to view their home directories as a Samba share. It also shares all printers configured for the system as Samba shared printers. You can attach a printer to the system and print to it from the Windows machines on your network.

15.1.5.1. Graphical Configuration

To configure Samba using a graphical interface, use one of the available Samba graphical user interfaces. A list of available GUIs can be found at http://www.samba.org/samba/GUI/.

15.1.5.2. Command-Line Configuration

Samba uses /etc/samba/smb.conf as its configuration file. If you change this configuration file, the changes do not take effect until you restart the Samba daemon with the following command, as root:
~]# systemctl restart smb.service
To specify the Windows workgroup and a brief description of the Samba server, edit the following lines in your /etc/samba/smb.conf file:
workgroup = WORKGROUPNAME
server string = BRIEF COMMENT ABOUT SERVER
Replace WORKGROUPNAME with the name of the Windows workgroup to which this machine should belong. The BRIEF COMMENT ABOUT SERVER is optional and is used as the Windows comment about the Samba system.
To create a Samba share directory on your Linux system, add the following section to your /etc/samba/smb.conf file (after modifying it to reflect your needs and your system):

Example 15.1. An Example Configuration of a Samba Server

[sharename]
comment = Insert a comment here
path = /home/share/
valid users = tfox carole
writable = yes
create mask = 0765
The above example allows the users tfox and carole to read and write to the directory /home/share/, on the Samba server, from a Samba client.

15.1.5.3. Encrypted Passwords

Encrypted passwords are enabled by default because it is more secure to use them. To create a user with an encrypted password, use the smbpasswd utility:
smbpasswd -a username

15.1.6. Starting and Stopping Samba

To start a Samba server, type the following command in a shell prompt, as root:
~]# systemctl start smb.service

Important

To set up a domain member server, you must first join the domain or Active Directory using the net join command before starting the smb service. Also, it is recommended to run winbind before smbd.
To stop the server, type the following command in a shell prompt, as root:
~]# systemctl stop smb.service
The restart option is a quick way of stopping and then starting Samba. This is the most reliable way to make configuration changes take effect after editing the configuration file for Samba. Note that the restart option starts the daemon even if it was not running originally.
To restart the server, type the following command in a shell prompt, as root:
~]# systemctl restart smb.service
The condrestart (conditional restart) option only starts smb on the condition that it is currently running. This option is useful for scripts, because it does not start the daemon if it is not running.

Note

When the /etc/samba/smb.conf file is changed, Samba automatically reloads it after a few minutes. Issuing a manual restart or reload is just as effective.
To conditionally restart the server, type the following command, as root:
~]# systemctl try-restart smb.service
A manual reload of the /etc/samba/smb.conf file can be useful in case of a failed automatic reload by the smb service. To ensure that the Samba server configuration file is reloaded without restarting the service, type the following command, as root:
~]# systemctl reload smb.service
By default, the smb service does not start automatically at boot time. To configure Samba to start at boot time, type the following at a shell prompt as root:
~]# systemctl enable smb.service
See Chapter 9, Managing Services with systemd for more information regarding this tool.

15.1.7. Samba Security Modes

There are only two types of security modes for Samba, share-level and user-level, which are collectively known as security levels. Share-level security is deprecated and has been removed from Samba. Configurations containing this mode need to be migrated to use user-level security. User-level security can be implemented in one of three different ways. The different ways of implementing a security level are called security modes.

15.1.7.1. User-Level Security

User-level security is the default and recommended setting for Samba. Even if the security = user directive is not listed in the /etc/samba/smb.conf file, it is used by Samba. If the server accepts the client's user name and password, the client can then mount multiple shares without specifying a password for each instance. Samba can also accept session-based user name and password requests. The client maintains multiple authentication contexts by using a unique UID for each logon.
In the /etc/samba/smb.conf file, the security = user directive that sets user-level security is:
[GLOBAL]
...
security = user
...

Samba Guest Shares

As mentioned above, share-level security mode is deprecated. To configure a Samba guest share without using the security = share parameter, follow the procedure below:

Procedure 15.1. Configuring Samba Guest Shares

  1. Create a username map file, in this example /etc/samba/smbusers, and add the following line to it:
    nobody = guest
  2. Add the following directives to the main section in the /etc/samba/smb.conf file. Also, do not use the valid users directive:
    [GLOBAL]
    ...
    security = user
    map to guest = Bad User
    username map = /etc/samba/smbusers
    ...
    The username map directive provides a path to the username map file specified in the previous step.
  3. Add the following directive to the share section in the /ect/samba/smb.conf file. Do not use the valid users directive.
    [SHARE]
    ...
    guest ok = yes
    ...
The following sections describe other implementations of user-level security.

Domain Security Mode (User-Level Security)

In domain security mode, the Samba server has a machine account (domain security trust account) and causes all authentication requests to be passed through to the domain controllers. The Samba server is made into a domain member server by using the following directives in the /etc/samba/smb.conf file:
[GLOBAL]
...
security = domain
workgroup = MARKETING
...

Active Directory Security Mode (User-Level Security)

If you have an Active Directory environment, it is possible to join the domain as a native Active Directory member. Even if a security policy restricts the use of NT-compatible authentication protocols, the Samba server can join an ADS using Kerberos. Samba in Active Directory member mode can accept Kerberos tickets.
In the /etc/samba/smb.conf file, the following directives make Samba an Active Directory member server:
[GLOBAL]
...
security = ADS
realm = EXAMPLE.COM
password server = kerberos.example.com
...

15.1.7.2. Share-Level Security

With share-level security, the server accepts only a password without an explicit user name from the client. The server expects a password for each share, independent of the user name. There have been recent reports that Microsoft Windows clients have compatibility issues with share-level security servers. This mode is deprecated and has been removed from Samba. Configurations containing security = share should be updated to use user-level security. Follow the steps in Procedure 15.1, “Configuring Samba Guest Shares” to avoid using the security = share directive.

15.1.8. Samba Network Browsing

Network browsing enables Windows and Samba servers to appear in the Windows Network Neighborhood. Inside the Network Neighborhood, icons are represented as servers and if opened, the server's shares and printers that are available are displayed.
Network browsing capabilities require NetBIOS over TCP/IP. NetBIOS-based networking uses broadcast (UDP) messaging to accomplish browse list management. Without NetBIOS and WINS as the primary method for TCP/IP host name resolution, other methods such as static files (/etc/hosts) or DNS, must be used.
A domain master browser collates the browse lists from local master browsers on all subnets so that browsing can occur between workgroups and subnets. Also, the domain master browser should preferably be the local master browser for its own subnet.

15.1.8.1. Domain Browsing

By default, a Windows server PDC for a domain is also the domain master browser for that domain. A Samba server must not be set up as a domain master server in this type of situation.
For subnets that do not include the Windows server PDC, a Samba server can be implemented as a local master browser. Configuring the /etc/samba/smb.conf file for a local master browser (or no browsing at all) in a domain controller environment is the same as workgroup configuration (see Section 15.1.5, “Configuring a Samba Server”).

15.1.8.2. WINS (Windows Internet Name Server)

Either a Samba server or a Windows NT server can function as a WINS server. When a WINS server is used with NetBIOS enabled, UDP unicasts can be routed which allows name resolution across networks. Without a WINS server, the UDP broadcast is limited to the local subnet and therefore cannot be routed to other subnets, workgroups, or domains. If WINS replication is necessary, do not use Samba as your primary WINS server, as Samba does not currently support WINS replication.
In a mixed NT/2000/2003/2008 server and Samba environment, it is recommended that you use the Microsoft WINS capabilities. In a Samba-only environment, it is recommended that you use only one Samba server for WINS.
The following is an example of the /etc/samba/smb.conf file in which the Samba server is serving as a WINS server:

Example 15.2. An Example Configuration of WINS Server

[global]
wins support = yes

Note

All servers (including Samba) should connect to a WINS server to resolve NetBIOS names. Without WINS, browsing only occurs on the local subnet. Furthermore, even if a domain-wide list is somehow obtained, hosts cannot be resolved for the client without WINS.

15.1.9. Samba Distribution Programs

net

net <protocol> <function> <misc_options> <target_options>
The net utility is similar to the net utility used for Windows and MS-DOS. The first argument is used to specify the protocol to use when executing a command. The protocol option can be ads, rap, or rpc for specifying the type of server connection. Active Directory uses ads, Win9x/NT3 uses rap, and Windows NT4/2000/2003/2008 uses rpc. If the protocol is omitted, net automatically tries to determine it.
The following example displays a list of the available shares for a host named wakko:
~]$ net -l share -S wakko
Password:
Enumerating shared resources (exports) on remote server:
Share name   Type     Description
----------   ----     -----------
data         Disk     Wakko data share
tmp          Disk     Wakko tmp share
IPC$         IPC      IPC Service (Samba Server)
ADMIN$       IPC      IPC Service (Samba Server)
The following example displays a list of Samba users for a host named wakko:
~]$ net -l user -S wakko
root password:
User name             Comment
-----------------------------
andriusb              Documentation
joe                   Marketing
lisa                  Sales

nmblookup

nmblookup <options> <netbios_name>
The nmblookup program resolves NetBIOS names into IP addresses. The program broadcasts its query on the local subnet until the target machine replies.
The following example displays the IP address of the NetBIOS name trek:
~]$ nmblookup trek
querying trek on 10.1.59.255
10.1.56.45 trek<00>

pdbedit

pdbedit <options>
The pdbedit program manages accounts located in the SAM database. All back ends are supported including smbpasswd, LDAP, and the tdb database library.
The following are examples of adding, deleting, and listing users:
~]$ pdbedit -a kristin
new password:
retype new password:
Unix username:        kristin
NT username:
Account Flags:        [U          ]
User SID:             S-1-5-21-1210235352-3804200048-1474496110-2012
Primary Group SID:    S-1-5-21-1210235352-3804200048-1474496110-2077
Full Name: Home Directory:       \\wakko\kristin
HomeDir Drive:
Logon Script:
Profile Path:         \\wakko\kristin\profile
Domain:               WAKKO
Account desc:
Workstations: Munged
dial:
Logon time:           0
Logoff time:          Mon, 18 Jan 2038 22:14:07 GMT
Kickoff time:         Mon, 18 Jan 2038 22:14:07 GMT
Password last set:    Thu, 29 Jan 2004 08:29:28
GMT Password can change:  Thu, 29 Jan 2004 08:29:28 GMT
Password must change: Mon, 18 Jan 2038 22:14:07 GMT
~]$ pdbedit -v -L kristin
Unix username:        kristin
NT username:
Account Flags:        [U          ]
User SID:             S-1-5-21-1210235352-3804200048-1474496110-2012
Primary Group SID:    S-1-5-21-1210235352-3804200048-1474496110-2077
Full Name:
Home Directory:       \\wakko\kristin
HomeDir Drive:
Logon Script:
Profile Path:         \\wakko\kristin\profile
Domain:               WAKKO
Account desc:
Workstations: Munged
dial:
Logon time:           0
Logoff time:          Mon, 18 Jan 2038 22:14:07 GMT
Kickoff time:         Mon, 18 Jan 2038 22:14:07 GMT
Password last set:    Thu, 29 Jan 2004 08:29:28 GMT
Password can change:  Thu, 29 Jan 2004 08:29:28 GMT
Password must change: Mon, 18 Jan 2038 22:14:07 GMT
~]$ pdbedit -L
andriusb:505:
joe:503:
lisa:504:
kristin:506:
~]$ pdbedit -x joe
~]$ pdbedit -L
andriusb:505: lisa:504: kristin:506:

rpcclient

rpcclient <server> <options>
The rpcclient program issues administrative commands using Microsoft RPCs, which provide access to the Windows administration graphical user interfaces (GUIs) for systems management. This is most often used by advanced users that understand the full complexity of Microsoft RPCs.

smbcacls

smbcacls <//server/share> <filename> <options>
The smbcacls program modifies Windows ACLs on files and directories shared by a Samba server or a Windows server.

smbclient

smbclient <//server/share> <password> <options>
The smbclient program is a versatile UNIX client which provides functionality similar to the ftp utility.

smbcontrol

smbcontrol -i <options>
smbcontrol <options> <destination> <messagetype> <parameters>
The smbcontrol program sends control messages to running smbd, nmbd, or winbindd daemons. Executing smbcontrol -i runs commands interactively until a blank line or a 'q' is entered.

smbpasswd

smbpasswd <options> <username> <password>
The smbpasswd program manages encrypted passwords. This program can be run by a superuser to change any user's password and also by an ordinary user to change their own Samba password.

smbspool

smbspool <job> <user> <title> <copies> <options> <filename>
The smbspool program is a CUPS-compatible printing interface to Samba. Although designed for use with CUPS printers, smbspool can work with non-CUPS printers as well.

smbstatus

smbstatus <options>
The smbstatus program displays the status of current connections to a Samba server.

smbtar

smbtar <options>
The smbtar program performs backup and restores of Windows-based share files and directories to a local tape archive. Though similar to the tar utility, the two are not compatible.

testparm

testparm <options> <filename> <hostname IP_address>
The testparm program checks the syntax of the /etc/samba/smb.conf file. If your smb.conf file is in the default location (/etc/samba/smb.conf) you do not need to specify the location. Specifying the host name and IP address to the testparm program verifies that the hosts.allow and host.deny files are configured correctly. The testparm program also displays a summary of your smb.conf file and the server's role (stand-alone, domain, etc.) after testing. This is convenient when debugging as it excludes comments and concisely presents information for experienced administrators to read. For example:
~]$ testparm
Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Processing section "[printers]"
Processing section "[tmp]"
Processing section "[html]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions
<enter>
# Global parameters
[global]
	workgroup = MYGROUP
	server string = Samba Server
	security = SHARE
	log file = /var/log/samba/%m.log
	max log size = 50
	socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
	dns proxy = no
[homes]
	comment = Home Directories
	read only = no
	browseable = no
[printers]
	comment = All Printers
	path = /var/spool/samba
	printable = yes
	browseable = no
[tmp]
	comment = Wakko tmp
	path = /tmp
	guest only = yes
[html]
	comment = Wakko www
	path = /var/www/html
	force user = andriusb
	force group = users
	read only = no
	guest only = yes

wbinfo

wbinfo <options>
The wbinfo program displays information from the winbindd daemon. The winbindd daemon must be running for wbinfo to work.

15.1.10. Additional Resources

The following sections give you the means to explore Samba in greater detail.

Installed Documentation

  • /usr/share/doc/samba-<version-number>/ — All additional files included with the Samba distribution. This includes all helper scripts, sample configuration files, and documentation.
  • See the following man pages for detailed information specific Samba features:
    • smb.conf(5)
    • samba(7)
    • smbd(8)
    • nmbd(8)
    • winbindd(8)

Useful Websites

  • http://www.samba.org/ — Homepage for the Samba distribution and all official documentation created by the Samba development team. Many resources are available in HTML and PDF formats, while others are only available for purchase. Although many of these links are not Red Hat Enterprise Linux specific, some concepts may apply.
  • https://wiki.samba.org/index.php/User_Documentation — Upstream Samba Documentation.
  • http://samba.org/samba/archives.html — Active email lists for the Samba community. Enabling digest mode is recommended due to high levels of list activity.
  • Samba newsgroups — Samba threaded newsgroups, such as www.gmane.org, that use the NNTP protocol are also available. This an alternative to receiving mailing list emails.

15.2. FTP

The File Transfer Protocol (FTP) is one of the oldest and most commonly used protocols found on the Internet today. Its purpose is to reliably transfer files between computer hosts on a network without requiring the user to log directly in to the remote host or to have knowledge of how to use the remote system. It allows users to access files on remote systems using a standard set of simple commands.
This section outlines the basics of the FTP protocol and introduces vsftpd, which is the preferred FTP server in Red Hat Enterprise Linux.

15.2.1. The File Transfer Protocol

FTP uses a client-server architecture to transfer files using the TCP network protocol. Because FTP is a rather old protocol, it uses unencrypted user name and password authentication. For this reason, it is considered an insecure protocol and should not be used unless absolutely necessary. However, because FTP is so prevalent on the Internet, it is often required for sharing files to the public. System administrators, therefore, should be aware of FTP's unique characteristics.
This section describes how to configure vsftpd to establish connections secured by TLS and how to secure an FTP server with the help of SELinux. A good substitute for FTP is sftp from the OpenSSH suite of tools. For information about configuring OpenSSH and about the SSH protocol in general, refer to Chapter 11, OpenSSH.
Unlike most protocols used on the Internet, FTP requires multiple network ports to work properly. When an FTP client application initiates a connection to an FTP server, it opens port 21 on the server — known as the command port. This port is used to issue all commands to the server. Any data requested from the server is returned to the client via a data port. The port number for data connections, and the way in which data connections are initialized, vary depending upon whether the client requests the data in active or passive mode.
The following defines these modes:
active mode
Active mode is the original method used by the FTP protocol for transferring data to the client application. When an active-mode data transfer is initiated by the FTP client, the server opens a connection from port 20 on the server to the IP address and a random, unprivileged port (greater than 1024) specified by the client. This arrangement means that the client machine must be allowed to accept connections over any port above 1024. With the growth of insecure networks, such as the Internet, the use of firewalls for protecting client machines is now prevalent. Because these client-side firewalls often deny incoming connections from active-mode FTP servers, passive mode was devised.
passive mode
Passive mode, like active mode, is initiated by the FTP client application. When requesting data from the server, the FTP client indicates it wants to access the data in passive mode and the server provides the IP address and a random, unprivileged port (greater than 1024) on the server. The client then connects to that port on the server to download the requested information.
While passive mode does resolve issues for client-side firewall interference with data connections, it can complicate administration of the server-side firewall. You can reduce the number of open ports on a server by limiting the range of unprivileged ports on the FTP server. This also simplifies the process of configuring firewall rules for the server.

15.2.2. The vsftpd Server

The Very Secure FTP Daemon (vsftpd) is designed from the ground up to be fast, stable, and, most importantly, secure. vsftpd is the only stand-alone FTP server distributed with Red Hat Enterprise Linux, due to its ability to handle large numbers of connections efficiently and securely.
The security model used by vsftpd has three primary aspects:
  • Strong separation of privileged and non-privileged processes — Separate processes handle different tasks, and each of these processes runs with the minimal privileges required for the task.
  • Tasks requiring elevated privileges are handled by processes with the minimal privilege necessary — By taking advantage of compatibilities found in the libcap library, tasks that usually require full root privileges can be executed more safely from a less privileged process.
  • Most processes run in a chroot jail — Whenever possible, processes are change-rooted to the directory being shared; this directory is then considered a chroot jail. For example, if the /var/ftp/ directory is the primary shared directory, vsftpd reassigns /var/ftp/ to the new root directory, known as /. This disallows any potential malicious hacker activities for any directories not contained in the new root directory.
Use of these security practices has the following effect on how vsftpd deals with requests:
  • The parent process runs with the least privileges required — The parent process dynamically calculates the level of privileges it requires to minimize the level of risk. Child processes handle direct interaction with the FTP clients and run with as close to no privileges as possible.
  • All operations requiring elevated privileges are handled by a small parent process — Much like the Apache HTTP Server, vsftpd launches unprivileged child processes to handle incoming connections. This allows the privileged, parent process to be as small as possible and handle relatively few tasks.
  • All requests from unprivileged child processes are distrusted by the parent process — Communication with child processes is received over a socket, and the validity of any information from child processes is checked before being acted on.
  • Most interactions with FTP clients are handled by unprivileged child processes in a chroot jail — Because these child processes are unprivileged and only have access to the directory being shared, any crashed processes only allow the attacker access to the shared files.

15.2.2.1. Starting and Stopping vsftpd

To start the vsftpd service in the current session, type the following at a shell prompt as root:
~]# systemctl start vsftpd.service
To stop the service in the current session, type as root:
~]# systemctl stop vsftpd.service
To restart the vsftpd service, run the following command as root:
~]# systemctl restart vsftpd.service
This command stops and immediately starts the vsftpd service, which is the most efficient way to make configuration changes take effect after editing the configuration file for this FTP server. Alternatively, you can use the following command to restart the vsftpd service only if it is already running:
~]# systemctl try-restart vsftpd.service
By default, the vsftpd service does not start automatically at boot time. To configure the vsftpd service to start at boot time, type the following at a shell prompt as root:
~]# systemctl enable vsftpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/vsftpd.service to /usr/lib/systemd/system/vsftpd.service.
For more information on how to manage system services in Red Hat Enterprise Linux 7, see Chapter 9, Managing Services with systemd.

15.2.2.2. Starting Multiple Copies of vsftpd

Sometimes, one computer is used to serve multiple FTP domains. This is a technique called multihoming. One way to multihome using vsftpd is by running multiple copies of the daemon, each with its own configuration file.
To do this, first assign all relevant IP addresses to network devices or alias network devices on the system. For more information about configuring network devices, device aliases, and additional information about network configuration scripts, see the Red Hat Enterprise Linux 7 Networking Guide.
Next, the DNS server for the FTP domains must be configured to reference the correct machine. For information about BIND, the DNS protocol implementation used in Red Hat Enterprise Linux, and its configuration files, see the Red Hat Enterprise Linux 7 Networking Guide.
For vsftpd to answer requests on different IP addresses, multiple copies of the daemon must be running. To facilitate launching multiple instances of the vsftpd daemon, a special systemd service unit (vsftpd@.service) for launching vsftpd as an instantiated service is supplied in the vsftpd package.
In order to make use of this service unit, a separate vsftpd configuration file for each required instance of the FTP server must be created and placed in the /etc/vsftpd/ directory. Note that each of these configuration files must have a unique name (such as /etc/vsftpd/vsftpd-site-2.conf) and must be readable and writable only by the root user.
Within each configuration file for each FTP server listening on an IPv4 network, the following directive must be unique:
listen_address=N.N.N.N
Replace N.N.N.N with a unique IP address for the FTP site being served. If the site is using IPv6, use the listen_address6 directive instead.
Once there are multiple configuration files present in the /etc/vsftpd/ directory, individual instances of the vsftpd daemon can be started by executing the following command as root:
~]# systemctl start vsftpd@configuration-file-name.service
In the above command, replace configuration-file-name with the unique name of the requested server's configuration file, such as vsftpd-site-2. Note that the configuration file's .conf extension should not be included in the command.
If you want to start several instances of the vsftpd daemon at once, you can make use of a systemd target unit file (vsftpd.target), which is supplied in the vsftpd package. This systemd target causes an independent vsftpd daemon to be launched for each available vsftpd configuration file in the /etc/vsftpd/ directory. Execute the following command as root to enable the target:
~]# systemctl enable vsftpd.target
Created symlink from /etc/systemd/system/multi-user.target.wants/vsftpd.target to /usr/lib/systemd/system/vsftpd.target.
The above command configures the systemd service manager to launch the vsftpd service (along with the configured vsftpd server instances) at boot time. To start the service immediately, without rebooting the system, execute the following command as root:
~]# systemctl start vsftpd.target
See Section 9.3, “Working with systemd Targets” for more information on how to use systemd targets to manage services.
Other directives to consider altering on a per-server basis are:
  • anon_root
  • local_root
  • vsftpd_log_file
  • xferlog_file

15.2.2.3. Encrypting vsftpd Connections Using TLS

In order to counter the inherently insecure nature of FTP, which transmits user names, passwords, and data without encryption by default, the vsftpd daemon can be configured to utilize the TLS protocol to authenticate connections and encrypt all transfers. Note that an FTP client that supports TLS is needed to communicate with vsftpd with TLS enabled.

Note

SSL (Secure Sockets Layer) is the name of an older implementation of the security protocol. The new versions are called TLS (Transport Layer Security). Only the newer versions (TLS) should be used as SSL suffers from serious security vulnerabilities. The documentation included with the vsftpd server, as well as the configuration directives used in the vsftpd.conf file, use the SSL name when referring to security-related matters, but TLS is supported and used by default when the ssl_enable directive is set to YES.
Set the ssl_enable configuration directive in the vsftpd.conf file to YES to turn on TLS support. The default settings of other TLS-related directives that become automatically active when the ssl_enable option is enabled provide for a reasonably well-configured TLS set up. This includes, among other things, the requirement to only use the TLS v1 protocol for all connections (the use of the insecure SSL protocol versions is disabled by default) or forcing all non-anonymous logins to use TLS for sending passwords and data transfers.

Example 15.3. Configuring vsftpd to Use TLS

In this example, the configuration directives explicitly disable the older SSL versions of the security protocol in the vsftpd.conf file:
ssl_enable=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
Restart the vsftpd service after you modify its configuration:
~]# systemctl restart vsftpd.service
See the vsftpd.conf(5) manual page for other TLS-related configuration directives for fine-tuning the use of TLS by vsftpd.

15.2.2.4. SELinux Policy for vsftpd

The SELinux policy governing the vsftpd daemon (as well as other ftpd processes), defines a mandatory access control, which, by default, is based on least access required. In order to allow the FTP daemon to access specific files or directories, appropriate labels need to be assigned to them.
For example, in order to be able to share files anonymously, the public_content_t label must be assigned to the files and directories to be shared. You can do this using the chcon command as root:
~]# chcon -R -t public_content_t /path/to/directory
In the above command, replace /path/to/directory with the path to the directory to which you want to assign the label. Similarly, if you want to set up a directory for uploading files, you need to assign that particular directory the public_content_rw_t label. In addition to that, the allow_ftpd_anon_write SELinux Boolean option must be set to 1. Use the setsebool command as root to do that:
~]# setsebool -P allow_ftpd_anon_write=1
If you want local users to be able to access their home directories through FTP, which is the default setting on Red Hat Enterprise Linux 7, the ftp_home_dir Boolean option needs to be set to 1. If vsftpd is to be allowed to run in standalone mode, which is also enabled by default on Red Hat Enterprise Linux 7, the ftpd_is_daemon option needs to be set to 1 as well.
See the ftpd_selinux(8) manual page for more information, including examples of other useful labels and Boolean options, on how to configure the SELinux policy pertaining to FTP. Also, see the Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide for more detailed information about SELinux in general.

15.2.3. Additional Resources

For more information about vsftpd, see the following resources.

15.2.3.1. Installed Documentation

  • The /usr/share/doc/vsftpd-version-number/ directory — Replace version-number with the installed version of the vsftpd package. This directory contains a README file with basic information about the software. The TUNING file contains basic performance-tuning tips and the SECURITY/ directory contains information about the security model employed by vsftpd.
  • vsftpd-related manual pages — There are a number of manual pages for the daemon and the configuration files. The following lists some of the more important manual pages.
    Server Applications
    • vsftpd(8) — Describes available command-line options for vsftpd.
    Configuration Files
    • vsftpd.conf(5) — Contains a detailed list of options available within the configuration file for vsftpd.
    • hosts_access(5) — Describes the format and options available within the TCP wrappers configuration files: hosts.allow and hosts.deny.
    Interaction with SELinux
    • ftpd_selinux(8) — Contains a description of the SELinux policy governing ftpd processes as well as an explanation of the way SELinux labels need to be assigned and Booleans set.

15.2.3.2. Online Documentation

About vsftpd and FTP in General
Red Hat Enterprise Linux Documentation
  • Red Hat Enterprise Linux 7 Networking Guide — The Networking Guide for Red Hat Enterprise Linux 7 documents relevant information regarding the configuration and administration of network interfaces, networks, and network services in this system. It provides an introduction to the hostnamectl utility and explains how to use it to view and set host names on the command line, both locally and remotely.
  • Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide — The SELinux User's and Administrator's Guide for Red Hat Enterprise Linux 7 describes the basic principles of SELinux and documents in detail how to configure and use SELinux with various services such as the Apache HTTP Server, Postfix, PostgreSQL, or OpenShift. It explains how to configure SELinux access permissions for system services managed by systemd.
  • Red Hat Enterprise Linux 7 Security Guide — The Security Guide for Red Hat Enterprise Linux 7 assists users and administrators in learning the processes and practices of securing their workstations and servers against local and remote intrusion, exploitation, and malicious activity. It also explains how to secure critical system services.
Relevant RFC Documents
  • RFC 0959 — The original Request for Comments (RFC) of the FTP protocol from the IETF.
  • RFC 1123 — The small FTP-related section extends and clarifies RFC 0959.
  • RFC 2228FTP security extensions. vsftpd implements the small subset needed to support TLS and SSL connections.
  • RFC 2389 — Proposes FEAT and OPTS commands.
  • RFC 2428IPv6 support.

15.3. Print Settings

The Print Settings tool serves for printer configuring, maintenance of printer configuration files, print spool directories and print filters, and printer classes management.
The tool is based on the Common Unix Printing System (CUPS). If you upgraded the system from a