Product SiteDocumentation Site

Fedora 24

System Administrator's Guide

Deployment, Configuration, and Administration of Fedora 24

Edition 1.0

Stephen Wadeley

Red Hat Customer Content Services

Jaromír Hradílek

Red Hat Customer Content Services

Petr Bokoč

Red Hat Customer Content Services

Petr Kovář

Red Hat Customer Content Services

Tomáš Čapek

Red Hat Customer Content Services

Douglas Silas

Red Hat Customer Content Services

Martin Prpič

Red Hat Customer Content Services

Eliška Slobodová

Red Hat Customer Content Services

Miroslav Svoboda

Red Hat Customer Content Services

John Ha

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

Legal Notice

Copyright © 2016 Red Hat, Inc. and others.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
For guidelines on the permitted uses of the Fedora trademarks, refer to https://fedoraproject.org/wiki/Legal:Trademark_guidelines.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
All other trademarks are the property of their respective owners.
Abstract
The System Administrator's Guide documents relevant information regarding the deployment, configuration, and administration of Fedora 24. It is oriented towards system administrators with a basic understanding of the system.

Preface
1. Target Audience
2. How to Read this Book
3. Document Conventions
3.1. Typographic Conventions
3.2. Pull-quote Conventions
3.3. Notes and Warnings
4. We Need Feedback!
5. Acknowledgments
I. Basic System Configuration
1. Opening Graphical Applications
1.1. Opening graphical applications from the command line
1.2. Launching Applications with Alt+F2
1.3. Launching applications from the Desktop Menu
1.3.1. Using GNOME menus
1.3.2. Using KDE menus
1.3.3. Using menus in LXDE, MATE, and XFCE
2. System Locale and Keyboard Configuration
2.1. Setting the System Locale
2.1.1. Displaying the Current Status
2.1.2. Listing Available Locales
2.1.3. Setting the Locale
2.2. Changing the Keyboard Layout
2.2.1. Displaying the Current Settings
2.2.2. Listing Available Keymaps
2.2.3. Setting the Keymap
2.3. Additional Resources
3. Configuring the Date and Time
3.1. Using the timedatectl Command
3.1.1. Displaying the Current Date and Time
3.1.2. Changing the Current Time
3.1.3. Changing the Current Date
3.1.4. Changing the Time Zone
3.1.5. Synchronizing the System Clock with a Remote Server
3.2. Using the date Command
3.2.1. Displaying the Current Date and Time
3.2.2. Changing the Current Time
3.2.3. Changing the Current Date
3.3. Using the hwclock Command
3.3.1. Displaying the Current Date and Time
3.3.2. Setting the Date and Time
3.3.3. Synchronizing the Date and Time
3.4. Additional Resources
4. Managing Users and Groups
4.1. Introduction to Users and Groups
4.1.1. User Private Groups
4.1.2. Shadow Passwords
4.2. Managing Users in a Graphical Environment
4.2.1. Using the Users Settings Tool
4.3. Using Command Line Tools
4.3.1. Adding a New User
4.3.2. Adding a New Group
4.3.3. Enabling Password Aging
4.3.4. Enabling Automatic Logouts
4.3.5. Creating Group Directories
4.4. Additional Resources
5. Gaining Privileges
5.1. The su Command
5.2. The sudo Command
5.3. Additional Resources
II. Package Management
6. DNF
6.1. Checking For and Updating Packages
6.1.1. Checking For Updates
6.1.2. Updating Packages
6.1.3. Preserving Configuration File Changes
6.2. Packages and Package Groups
6.2.1. Searching Packages
6.2.2. Listing Packages
6.2.3. Displaying Package Information
6.2.4. Installing Packages
6.2.5. Removing Packages
6.2.6. Working with Transaction History
6.3. Configuring DNF and DNF Repositories
6.3.1. Setting [main] Options
6.3.2. Setting [repository] Options
6.3.3. Using DNF Variables
6.4. Viewing the Current Configuration
6.5. Adding, Enabling, and Disabling a DNF Repository
6.6. Additional Resources
III. Infrastructure Services
7. Services and Daemons
7.1. Configuring Services
7.1.1. Enabling the Service
7.1.2. Disabling the Service
7.2. Running Services
7.2.1. Checking the Service Status
7.2.2. Running the Service
7.2.3. Stopping the Service
7.2.4. Restarting the Service
7.3. Additional Resources
7.3.1. Installed Documentation
7.3.2. Related Books
8. OpenSSH
8.1. The SSH Protocol
8.1.1. Why Use SSH?
8.1.2. Main Features
8.1.3. Protocol Versions
8.1.4. Event Sequence of an SSH Connection
8.2. Configuring OpenSSH
8.2.1. Configuration Files
8.2.2. Starting an OpenSSH Server
8.2.3. Requiring SSH for Remote Connections
8.2.4. Using Key-based Authentication
8.3. Using OpenSSH Certificate Authentication
8.3.1. Introduction to SSH Certificates
8.3.2. Support for SSH Certificates
8.3.3. Creating SSH CA Certificate Signing Keys
8.3.4. Distributing and Trusting SSH CA Public Keys
8.3.5. Creating SSH Certificates
8.3.6. Signing an SSH Certificate Using a PKCS#11 Token
8.3.7. Viewing an SSH CA Certificate
8.3.8. Revoking an SSH CA Certificate
8.4. OpenSSH Clients
8.4.1. Using the ssh Utility
8.4.2. Using the scp Utility
8.4.3. Using the sftp Utility
8.5. More Than a Secure Shell
8.5.1. X11 Forwarding
8.5.2. Port Forwarding
8.6. Additional Resources
9. TigerVNC
9.1. VNC Server
9.1.1. Installing VNC Server
9.1.2. Configuring VNC Server
9.1.3. Starting VNC Server
9.1.4. Terminating a VNC Session
9.2. VNC Viewer
9.2.1. Installing VNC Viewer
9.2.2. Connecting to VNC Server
9.2.3. Connecting to VNC Server Using SSH
9.3. Additional Resources
IV. Servers
10. Web Servers
10.1. The Apache HTTP Server
10.1.1. Notable Changes
10.1.2. Updating the Configuration
10.1.3. Running the httpd Service
10.1.4. Editing the Configuration Files
10.1.5. Working with Modules
10.1.6. Setting Up Virtual Hosts
10.1.7. Setting Up an SSL Server
10.1.8. Additional Resources
11. Mail Servers
11.1. Email Protocols
11.1.1. Mail Transport Protocols
11.1.2. Mail Access Protocols
11.2. Email Program Classifications
11.2.1. Mail Transport Agent
11.2.2. Mail Delivery Agent
11.2.3. Mail User Agent
11.3. Mail Transport Agents
11.3.1. Postfix
11.3.2. Sendmail
11.3.3. Fetchmail
11.3.4. Mail Transport Agent (MTA) Configuration
11.4. Mail Delivery Agents
11.4.1. Procmail Configuration
11.4.2. Procmail Recipes
11.5. Mail User Agents
11.5.1. Securing Communication
11.6. Additional Resources
11.6.1. Installed Documentation
11.6.2. Useful Websites
11.6.3. Related Books
12. Directory Servers
12.1. OpenLDAP
12.1.1. Introduction to LDAP
12.1.2. Installing the OpenLDAP Suite
12.1.3. Configuring an OpenLDAP Server
12.1.4. SELinux Policy for Applications Using LDAP
12.1.5. Running an OpenLDAP Server
12.1.6. Configuring a System to Authenticate Using OpenLDAP
12.1.7. Additional Resources
12.1.8. Related Books
13. File and Print Servers
13.1. Samba
13.1.1. Introduction to Samba
13.1.2. Samba Daemons and Related Services
13.1.3. Connecting to a Samba Share
13.1.4. Mounting the Share
13.1.5. Configuring a Samba Server
13.1.6. Starting and Stopping Samba
13.1.7. Samba Server Types and the smb.conf File
13.1.8. Samba Security Modes
13.1.9. Samba Account Information Databases
13.1.10. Samba Network Browsing
13.1.11. Samba with CUPS Printing Support
13.1.12. Samba Distribution Programs
13.1.13. Additional Resources
13.2. FTP
13.2.1. The File Transfer Protocol
13.2.2. FTP Servers
13.2.3. Files Installed with vsftpd
13.2.4. Starting and Stopping vsftpd
13.2.5. vsftpd Configuration Options
13.2.6. Additional Resources
13.3. Printer Configuration
13.3.1. Starting the Printers Configuration Tool
13.3.2. Starting Printer Setup
13.3.3. Adding a Local Printer
13.3.4. Adding an AppSocket/HP JetDirect printer
13.3.5. Adding an IPP Printer
13.3.6. Adding an LPD/LPR Host or Printer
13.3.7. Adding a Samba (SMB) printer
13.3.8. Selecting the Printer Model and Finishing
13.3.9. Printing a Test Page
13.3.10. Modifying Existing Printers
13.3.11. Additional Resources
14. Configuring NTP Using the chrony Suite
14.1. Introduction to the chrony Suite
14.1.1. Differences Between ntpd and chronyd
14.1.2. Choosing Between NTP Daemons
14.2. Understanding chrony and Its Configuration
14.2.1. Understanding chronyd
14.2.2. Understanding chronyc
14.2.3. Understanding the chrony Configuration Commands
14.2.4. Security with chronyc
14.3. Using chrony
14.3.1. Installing chrony
14.3.2. Checking the Status of chronyd
14.3.3. Starting chronyd
14.3.4. Stopping chronyd
14.3.5. Checking if chrony is Synchronized
14.3.6. Manually Adjusting the System Clock
14.4. Setting Up chrony for Different Environments
14.4.1. Setting Up chrony for a System Which is Infrequently Connected
14.4.2. Setting Up chrony for a System in an Isolated Network
14.5. Using chronyc
14.5.1. Using chronyc to Control chronyd
14.5.2. Using chronyc for Remote Administration
14.6. Additional Resources
14.6.1. Installed Documentation
14.6.2. Online Documentation
15. Configuring NTP Using ntpd
15.1. Introduction to NTP
15.2. NTP Strata
15.3. Understanding NTP
15.4. Understanding the Drift File
15.5. UTC, Timezones, and DST
15.6. Authentication Options for NTP
15.7. Managing the Time on Virtual Machines
15.8. Understanding Leap Seconds
15.9. Understanding the ntpd Configuration File
15.10. Understanding the ntpd Sysconfig File
15.11. Disabling chrony
15.12. Checking if the NTP Daemon is Installed
15.13. Installing the NTP Daemon (ntpd)
15.14. Checking the Status of NTP
15.15. Configure the Firewall to Allow Incoming NTP Packets
15.15.1. Change the Firewall Settings
15.15.2. Open Ports in the Firewall for NTP Packets
15.16. Configure ntpdate Servers
15.17. Configure NTP
15.17.1. Configure Access Control to an NTP Service
15.17.2. Configure Rate Limiting Access to an NTP Service
15.17.3. Adding a Peer Address
15.17.4. Adding a Server Address
15.17.5. Adding a Broadcast or Multicast Server Address
15.17.6. Adding a Manycast Client Address
15.17.7. Adding a Broadcast Client Address
15.17.8. Adding a Manycast Server Address
15.17.9. Adding a Multicast Client Address
15.17.10. Configuring the Burst Option
15.17.11. Configuring the iburst Option
15.17.12. Configuring Symmetric Authentication Using a Key
15.17.13. Configuring the Poll Interval
15.17.14. Configuring Server Preference
15.17.15. Configuring the Time-to-Live for NTP Packets
15.17.16. Configuring the NTP Version to Use
15.18. Configuring the Hardware Clock Update
15.19. Configuring Clock Sources
15.20. Additional Resources
15.20.1. Installed Documentation
15.20.2. Useful Websites
16. Configuring PTP Using ptp4l
16.1. Introduction to PTP
16.1.1. Understanding PTP
16.1.2. Advantages of PTP
16.2. Using PTP
16.2.1. Checking for Driver and Hardware Support
16.2.2. Installing PTP
16.2.3. Starting ptp4l
16.3. Specifying a Configuration File
16.4. Using the PTP Management Client
16.5. Synchronizing the Clocks
16.6. Verifying Time Synchronization
16.7. Serving PTP Time with NTP
16.8. Serving NTP Time with PTP
16.9. Synchronize to PTP or NTP Time Using timemaster
16.9.1. Starting timemaster as a Service
16.9.2. Understanding the timemaster Configuration File
16.9.3. Configuring timemaster Options
16.10. Improving Accuracy
16.11. Additional Resources
16.11.1. Installed Documentation
16.11.2. Useful Websites
V. Monitoring and Automation
17. System Monitoring Tools
17.1. Viewing System Processes
17.1.1. Using the ps Command
17.1.2. Using the top Command
17.1.3. Using the System Monitor Tool
17.2. Viewing Memory Usage
17.2.1. Using the free Command
17.2.2. Using the System Monitor Tool
17.3. Viewing CPU Usage
17.3.1. Using the System Monitor Tool
17.4. Viewing Block Devices and File Systems
17.4.1. Using the lsblk Command
17.4.2. Using the blkid Command
17.4.3. Using the partx Command
17.4.4. Using the findmnt Command
17.4.5. Using the df Command
17.4.6. Using the du Command
17.4.7. Using the System Monitor Tool
17.5. Viewing Hardware Information
17.5.1. Using the lspci Command
17.5.2. Using the lsusb Command
17.5.3. Using the lspcmcia Command
17.5.4. Using the lscpu Command
17.6. Monitoring Performance with Net-SNMP
17.6.1. Installing Net-SNMP
17.6.2. Running the Net-SNMP Daemon
17.6.3. Configuring Net-SNMP
17.6.4. Retrieving Performance Data over SNMP
17.6.5. Extending Net-SNMP
17.7. Additional Resources
17.7.1. Installed Documentation
18. Viewing and Managing Log Files
18.1. Locating Log Files
18.2. Basic Configuration of Rsyslog
18.2.1. Filters
18.2.2. Actions
18.2.3. Templates
18.2.4. Global Directives
18.2.5. Log Rotation
18.3. Using the New Configuration Format
18.3.1. Rulesets
18.3.2. Compatibility with syslogd
18.4. Working with Queues in Rsyslog
18.4.1. Defining Queues
18.4.2. Managing Queues
18.5. Configuring rsyslog on a Logging Server
18.5.1. Using The New Template Syntax on a Logging Server
18.6. Using Rsyslog Modules
18.6.1. Importing Text Files
18.6.2. Exporting Messages to a Database
18.6.3. Enabling Encrypted Transport
18.6.4. Using RELP
18.7. Interaction of Rsyslog and Journal
18.8. Structured Logging with Rsyslog
18.8.1. Importing Data from Journal
18.8.2. Filtering Structured Messages
18.8.3. Parsing JSON
18.8.4. Storing Messages in the MongoDB
18.9. Debugging Rsyslog
18.10. Troubleshooting Logging to a Server
18.11. Using the Journal
18.11.1. Viewing Log Files
18.11.2. Access Control
18.11.3. Using The Live View
18.11.4. Filtering Messages
18.11.5. Enabling Persistent Storage
18.12. Managing Log Files in a Graphical Environment
18.12.1. Viewing Log Files
18.12.2. Adding a Log File
18.12.3. Monitoring Log Files
18.13. Additional Resources
19. Automating System Tasks
19.1. Cron and Anacron
19.1.1. Installing Cron and Anacron
19.1.2. Running the Crond Service
19.1.3. Configuring Anacron Jobs
19.1.4. Configuring Cron Jobs
19.1.5. Controlling Access to Cron
19.1.6. Black and White Listing of Cron Jobs
19.2. At and Batch
19.2.1. Installing At and Batch
19.2.2. Running the At Service
19.2.3. Configuring an At Job
19.2.4. Configuring a Batch Job
19.2.5. Viewing Pending Jobs
19.2.6. Additional Command Line Options
19.2.7. Controlling Access to At and Batch
19.3. Additional Resources
20. OProfile
20.1. Overview of Tools
20.1.1. operf vs. opcontrol
20.2. Using operf
20.2.1. Specifying the Kernel
20.2.2. Setting Events to Monitor
20.2.3. Categorization of Samples
20.3. Configuring OProfile Using Legacy Mode
20.3.1. Specifying the Kernel
20.3.2. Setting Events to Monitor
20.3.3. Separating Kernel and User-space Profiles
20.4. Starting and Stopping OProfile Using Legacy Mode
20.5. Saving Data in Legacy Mode
20.6. Analyzing the Data
20.6.1. Using opreport
20.6.2. Using opreport on a Single Executable
20.6.3. Getting More Detailed Output on the Modules
20.6.4. Using opannotate
20.7. Understanding the /dev/oprofile/ directory
20.8. Example Usage
20.9. OProfile Support for Java
20.9.1. Profiling Java Code
20.10. Graphical Interface
20.11. OProfile and SystemTap
20.12. Additional Resources
VI. Kernel, Module and Driver Configuration
21. Working with the GRUB 2 Boot Loader
21.1. Introduction to GRUB 2
21.2. Configuring the GRUB 2 Boot Loader
21.3. Making Temporary Changes to a GRUB 2 Menu
21.4. Making Persistent Changes to a GRUB 2 Menu Using the grubby Tool
21.5. Customizing the GRUB 2 Configuration File
21.5.1. Changing the Default Boot Entry
21.5.2. Editing a Menu Entry
21.5.3. Adding a new Entry
21.5.4. Creating a Custom Menu
21.6. GRUB 2 Password Protection
21.6.1. Setting Up Users and Password Protection, Specifying Menu Entries
21.6.2. Password Encryption
21.7. Reinstalling GRUB 2
21.7.1. Reinstalling GRUB 2 on BIOS-Based Machines
21.7.2. Reinstalling GRUB 2 on UEFI-Based Machines
21.7.3. Resetting and Reinstalling GRUB 2
21.8. GRUB 2 over a Serial Console
21.8.1. Configuring the GRUB 2 Menu
21.8.2. Using screen to Connect to the Serial Console
21.9. Terminal Menu Editing During Boot
21.9.1. Booting to Rescue Mode
21.9.2. Booting to Emergency Mode
21.9.3. Changing and Resetting the Root Password
21.10. UEFI Secure Boot
21.10.1. UEFI Secure Boot Support in Fedora
21.11. Additional Resources
22. Manually Upgrading the Kernel
22.1. Overview of Kernel Packages
22.2. Preparing to Upgrade
22.3. Downloading the Upgraded Kernel
22.4. Performing the Upgrade
22.5. Verifying the Initial RAM Disk Image
22.6. Verifying the Boot Loader
22.6.1. Configuring the GRUB 2 Boot Loader
22.6.2. Configuring the OS/400 Boot Loader
22.6.3. Configuring the YABOOT Boot Loader
23. Working with Kernel Modules
23.1. Listing Currently-Loaded Modules
23.2. Displaying Information About a Module
23.3. Loading a Module
23.4. Unloading a Module
23.5. Setting Module Parameters
23.6. Persistent Module Loading
23.7. Signing Kernel Modules for Secure Boot
23.7.1. Prerequisites
23.7.2. Kernel Module Authentication
23.7.3. Generating a Public and Private X.509 Key Pair
23.7.4. Enrolling Public Key on Target System
23.7.5. Signing Kernel Module with the Private Key
23.7.6. Loading Signed Kernel Module
23.8. Additional Resources
A. RPM
A.1. RPM Design Goals
A.2. Using RPM
A.2.1. Installing and Upgrading Packages
A.2.2. Uninstalling Packages
A.2.3. Freshening Packages
A.2.4. Querying Packages
A.2.5. Verifying Packages
A.3. Finding and Verifying RPM Packages
A.3.1. Finding RPM Packages
A.3.2. Checking Package Signatures
A.4. Common Examples of RPM Usage
A.5. Additional Resources
B. Revision History
Index

Preface

The System Administrator's Guide contains information on how to customize the Fedora 24 system to fit your needs. If you are looking for a comprehensive, task-oriented guide for configuring and customizing your system, this is the manual for you.
This manual discusses many intermediate topics such as the following:
  • Installing and managing packages using DNF
  • Configuring Apache HTTP Server, Postfix, Sendmail and other enterprise-class servers and software
  • Working with kernel modules and upgrading the kernel

Note

Some of the graphical procedures and menu locations are specific to GNOME, but most command line instructions will be universally applicable.

1. Target Audience

The System Administrator's Guide assumes you have a basic understanding of the Fedora operating system. If you need help with the installation of this system, refer to the Fedora Installation Guide.

2. How to Read this Book

This manual is divided into the following main categories:
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, Opening Graphical Applications describes methods for opening Graphical User Interface, or GUI, applications in various environments.
Chapter 2, System Locale and Keyboard Configuration covers basic language and keyboard setup. Read this chapter if you need to configure the language of your desktop, change the keyboard layout, or add the keyboard layout indicator to the panel.
Chapter 3, Configuring the Date and Time covers the configuration of the system date and time. Read this chapter if you need to set or change the date and time.
Chapter 4, Managing Users and Groups covers the management of users and groups in a graphical user interface and on the command line. Read this chapter if you need to manage users and groups on your system, or enable password aging.
Chapter 5, Gaining Privileges covers ways to gain administrative privileges using setuid programs such as su and sudo.
Part II, “Package Management”
This part describes how to manage software packages on Fedora using DNF.
Chapter 6, DNF describes the DNF package manager. Read this chapter for information how to search, install, update, and uninstall packages on the command line.
Part III, “Infrastructure Services”
This part provides information on how to configure services and daemons, configure authentication, and enable remote logins.
Chapter 7, Services and Daemons covers the configuration of the services to be run when a system is started, and provides information on how to start, stop, and restart the services on the command line using the systemctl utility.
Chapter 8, OpenSSH describes how to enable a remote login via the SSH protocol. It covers the configuration of the sshd service, as well as a basic usage of the ssh, scp, sftp client utilities. Read this chapter if you need a remote access to a machine.
Chapter 9, TigerVNC describes the virtual network computing (VNC) method of graphical desktop sharing which allows you to remotely control other computers.
Part IV, “Servers”
This part discusses various topics related to servers such as how to set up a Web server or share files and directories over the network.
Chapter 10, Web Servers focuses on the Apache HTTP Server 2.2, a robust, full-featured open source web server developed by the Apache Software Foundation. Read this chapter if you need to configure a web server on your system.
Chapter 11, Mail Servers reviews modern email protocols in use today, and some of the programs designed to send and receive email, including Postfix, Sendmail, Fetchmail, and Procmail. Read this chapter if you need to configure a mail server on your system.
Chapter 12, Directory Servers covers the installation and configuration of OpenLDAP 2.4, an open source implementation of the LDAPv2 and LDAPv3 protocols. Read this chapter if you need to configure a directory server on your system.
Chapter 13, File and Print Servers guides you through the installation and configuration of Samba, an open source implementation of the Server Message Block (SMB) protocol, and vsftpd, the primary FTP server shipped with Fedora. Additionally, it explains how to use the Printer Configuration tool to configure printers. Read this chapter if you need to configure a file or print server on your system.
Chapter 14, Configuring NTP Using the chrony Suite covers the installation and configuration of the chrony suite, a client and a server for the Network Time Protocol (NTP). Read this chapter if you need to configure the system to synchronize the clock with a remote NTP server, or set up an NTP server on this system.
Chapter 15, Configuring NTP Using ntpd covers the installation and configuration of the NTP daemon, ntpd, for the Network Time Protocol (NTP). Read this chapter if you need to configure the system to synchronize the clock with a remote NTP server, or set up an NTP server on this system, and you prefer not to use the chrony application.
Chapter 16, Configuring PTP Using ptp4l covers the installation and configuration of the Precision Time Protocol application, ptp4l, an application for use with network drivers that support the Precision Network Time Protocol (PTP). Read this chapter if you need to configure the system to synchronize the system clock with a master PTP clock.
Part V, “Monitoring and Automation”
This part describes various tools that allow system administrators to monitor system performance, automate system tasks, and report bugs.
Chapter 17, System Monitoring Tools discusses applications and commands that can be used to retrieve important information about the system. Read this chapter to learn how to gather essential system information.
Chapter 18, Viewing and Managing Log Files describes the configuration of the rsyslog daemon, and explains how to locate, view, and monitor log files. Read this chapter to learn how to work with log files.
Chapter 19, Automating System Tasks provides an overview of the cron, at, and batch utilities. Read this chapter to learn how to use these utilities to perform automated tasks.
Chapter 20, OProfile covers OProfile, a low overhead, system-wide performance monitoring tool. Read this chapter for information on how to use OProfile on your system.
Part VI, “Kernel, Module and Driver Configuration”
This part covers various tools that assist administrators with kernel customization.
Chapter 21, Working with the GRUB 2 Boot Loader describes the GNU GRand Unified Boot loader (GRUB) version 2 boot loader, which enables selecting an operating system or kernel to be loaded at system boot time.
Chapter 22, Manually Upgrading the Kernel provides important information on how to manually update a kernel package using the rpm command instead of dnf. Read this chapter if you cannot update a kernel package with the DNF package manager.
Chapter 23, Working with Kernel Modules explains how to display, query, load, and unload kernel modules and their dependencies, and how to set module parameters. Additionally, it covers specific kernel module capabilities such as using multiple Ethernet cards and using channel bonding. Read this chapter if you need to work with kernel modules.
Appendix A, RPM
This appendix concentrates on the RPM Package Manager (RPM), an open packaging system used by Fedora, and the use of the rpm utility. Read this appendix if you need to use rpm instead of dnf.

3. Document Conventions

This manual uses several conventions to highlight certain words and phrases and draw attention to specific pieces of information.
In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later includes the Liberation Fonts set by default.

3.1. Typographic Conventions

Four typographic conventions are used to call attention to specific words and phrases. These conventions, and the circumstances they apply to, are as follows.
Mono-spaced Bold
Used to highlight system input, including shell commands, file names and paths. Also used to highlight keycaps and key combinations. For example:
To see the contents of the file my_next_bestselling_novel in your current working directory, enter the cat my_next_bestselling_novel command at the shell prompt and press Enter to execute the command.
The above includes a file name, a shell command and a keycap, all presented in mono-spaced bold and all distinguishable thanks to context.
Key combinations can be distinguished from keycaps by the hyphen connecting each part of a key combination. For example:
Press Enter to execute the command.
Press Ctrl+Alt+F2 to switch to the first virtual terminal. Press Ctrl+Alt+F1 to return to your X-Windows session.
The first paragraph highlights the particular keycap to press. The second highlights two key combinations (each a set of three keycaps with each set pressed simultaneously).
If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in mono-spaced bold. For example:
File-related classes include filesystem for file systems, file for files, and dir for directories. Each class has its own associated set of permissions.
Proportional Bold
This denotes words or phrases encountered on a system, including application names; dialog box text; labeled buttons; check-box and radio button labels; menu titles and sub-menu titles. For example:
Choose SystemPreferencesMouse from the main menu bar to launch Mouse Preferences. In the Buttons tab, click the Left-handed mouse check box and click Close to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).
To insert a special character into a gedit file, choose ApplicationsAccessoriesCharacter Map from the main menu bar. Next, choose SearchFind… from the Character Map menu bar, type the name of the character in the Search field and click Next. The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the Copy button. Now switch back to your document and choose EditPaste from the gedit menu bar.
The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in proportional bold and all distinguishable by context.
Mono-spaced Bold Italic or Proportional Bold Italic
Whether mono-spaced bold or proportional bold, the addition of italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example:
To connect to a remote machine using ssh, type ssh username@domain.name at a shell prompt. If the remote machine is example.com and your username on that machine is john, type ssh john@example.com.
The mount -o remount file-system command remounts the named file system. For example, to remount the /home file system, the command is mount -o remount /home.
To see the version of a currently installed package, use the rpm -q package command. It will return a result as follows: package-version-release.
Note the words in bold italics above — username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system.
Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example:
Publican is a DocBook publishing system.

3.2. Pull-quote Conventions

Terminal output and source code listings are set off visually from the surrounding text.
Output sent to a terminal is set in mono-spaced roman and presented thus:
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
Source-code listings are also set in mono-spaced roman but add syntax highlighting as follows:
package org.jboss.book.jca.ex1;

import javax.naming.InitialContext;

public class ExClient
{
   public static void main(String args[]) 
       throws Exception
   {
      InitialContext iniCtx = new InitialContext();
      Object         ref    = iniCtx.lookup("EchoBean");
      EchoHome       home   = (EchoHome) ref;
      Echo           echo   = home.create();

      System.out.println("Created Echo");

      System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
   }
}

3.3. Notes and Warnings

Finally, we use three visual styles to draw attention to information that might otherwise be overlooked.

Note

Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier.

Important

Important boxes detail things that are easily missed: configuration changes that only apply to the current session, or services that need restarting before an update will apply. Ignoring a box labeled 'Important' will not cause data loss but may cause irritation and frustration.

Warning

Warnings should not be ignored. Ignoring warnings will most likely cause data loss.

4. We Need Feedback!

If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in Bugzilla: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora Documentation&component=system-administrator's-guide
If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.

5. Acknowledgments

Certain portions of this text first appeared in the Red Hat Enterprise Linux 7 System Administrator's Guide, copyright © 2014–2016 Red Hat, Inc., available at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/index.html.
Section 17.6, “Monitoring Performance with Net-SNMP” is based on an article written by Michael Solberg.
The authors of this book would like to thank the following people for their valuable contributions: Adam Tkáč, Andrew Fitzsimon, Andrius Benokraitis, Brian Cleary Edward Bailey, Garrett LeSage, Jeffrey Fearn, Joe Orton, Joshua Wulf, Karsten Wade, Lucy Ringland, Marcela Mašláňová, Mark Johnson, Michael Behm, Miroslav Lichvár, Radek Vokál, Rahul Kavalapara, Rahul Sundaram, Sandra Moore, Zbyšek Mráz, Jan Včelák, Peter Hutterer, T.C. Hollingsworth, and James Antill, among many others.

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.

Table of Contents

1. Opening Graphical Applications
1.1. Opening graphical applications from the command line
1.2. Launching Applications with Alt+F2
1.3. Launching applications from the Desktop Menu
1.3.1. Using GNOME menus
1.3.2. Using KDE menus
1.3.3. Using menus in LXDE, MATE, and XFCE
2. System Locale and Keyboard Configuration
2.1. Setting the System Locale
2.1.1. Displaying the Current Status
2.1.2. Listing Available Locales
2.1.3. Setting the Locale
2.2. Changing the Keyboard Layout
2.2.1. Displaying the Current Settings
2.2.2. Listing Available Keymaps
2.2.3. Setting the Keymap
2.3. Additional Resources
3. Configuring the Date and Time
3.1. Using the timedatectl Command
3.1.1. Displaying the Current Date and Time
3.1.2. Changing the Current Time
3.1.3. Changing the Current Date
3.1.4. Changing the Time Zone
3.1.5. Synchronizing the System Clock with a Remote Server
3.2. Using the date Command
3.2.1. Displaying the Current Date and Time
3.2.2. Changing the Current Time
3.2.3. Changing the Current Date
3.3. Using the hwclock Command
3.3.1. Displaying the Current Date and Time
3.3.2. Setting the Date and Time
3.3.3. Synchronizing the Date and Time
3.4. Additional Resources
4. Managing Users and Groups
4.1. Introduction to Users and Groups
4.1.1. User Private Groups
4.1.2. Shadow Passwords
4.2. Managing Users in a Graphical Environment
4.2.1. Using the Users Settings Tool
4.3. Using Command Line Tools
4.3.1. Adding a New User
4.3.2. Adding a New Group
4.3.3. Enabling Password Aging
4.3.4. Enabling Automatic Logouts
4.3.5. Creating Group Directories
4.4. Additional Resources
5. Gaining Privileges
5.1. The su Command
5.2. The sudo Command
5.3. Additional Resources

Chapter 1. Opening Graphical Applications

Fedora provides graphical applications in addition to command line utilities for configuring many features. This chapter describes methods for opening Graphical User Interface, or GUI, applications in various environments.

1.1. Opening graphical applications from the command line

Graphical applications can be launched from a terminal window or console session by simply typing the name of the application.
[fedorauser@localhost]$ firefox

File names vs Application names

Programs are opened from the command line using the name of the executable file provided in the program's package. An entry in the desktop menu will often be named differently from the file it executes. For example, the GNOME disk management utility appears in the menu as Disks, and the file it executes is /usr/bin/gnome-disks.
When a program is executed on the command line, the terminal is occupied until the program completes. When a graphical application is executed from the command line, the program's error output, or STDERR, is sent to the terminal window. This can be especially useful when troubleshooting.
Example 1.1. Viewing errors by launching graphical applications from the command line
[fedorauser@localhost]$ astromenace-wrapper
	AstroMenace 1.3.1 121212

	Open XML file: /home/fedorauser/.config/astromenace/amconfig.xml
	VFS file was opened /usr/share/astromenace/gamedata.vfs
	
	Vendor     : OpenAL Community
	Renderer   : OpenAL Soft
	Version    : 1.1 ALSOFT 1.15.1
	ALut ver   : 1.1

	Font initialized: DATA/FONT/LiberationMono-Bold.ttf

	Current Video Mode: 3200x1080 32bit

	Xinerama/TwinView detected.
	Screen count: 2
	Screen #0: (0, 0) x (1920, 1080)
	Screen #1: (1920, 0) x (1280, 1024)

	Supported resolutions list:
	640x480 16bit
	640x480 32bit
	640x480 0bit
	768x480 16bit
	<output truncated>

To launch a graphical application, but fork the additional output into the background and return the terminal for immediate use, use the shell's job control feature.
[fedorauser@localhost]$ emacs foo.txt &

Ending a session

Applications that hold the command line prompt until they complete will close when the terminal session ends, even if they are forked into the background.
GUI programs can also be launched on one TTY and displayed on another by specifying the DISPLAY variable. This can be useful when running multiple graphical sessions, or for troubleshooting problems with a desktop session.
  1. Switch to another TTY using the key combination Ctrl-Alt-F2 and log in. Note that consoles are available by default with F2 through F6.
  2. Identify the X session you want to target. The DISPLAY variable is always an integer preceded by a colon, and will be :0 in most cases. Check the arguments of the currently running X process to verify the value. The command below shows both the DISPLAY variable as well as the TTY that X is running on, tty1.
    [fedorauser@localhost]$ ps aux|grep /usr/bin/X
    root      1498  7.1  1.0 521396 353984 tty1    Ss+  00:04  66:34 /usr/bin/X :0 vt1 -background none -nolisten tcp -auth /var/run/kdm/A:0-22Degc
    
    root     23874  0.0  0.0 109184   900 pts/21   S+   15:35   0:00 grep --color=auto /usr/bin/X
  3. Specify the DISPLAY variable when executing the program.
    [fedorauser@localhost]$ DISPLAY=:0 gnome-shell --replace &
  4. Switch back to the TTY the graphical session is running on. Since the example above shows X running on vt1, pressing Ctrl+Alt+F1 will return to the desktop environment.

1.2.  Launching Applications with Alt+F2

Most desktop environments follow the convention of using the key combination Alt+F2 for opening new applications. Pressing Alt+F2 brings up a prompt for a command to be entered into.
Commands entered into this dialog box function much as they would if entered in a terminal. Applications are known by their file name, and can accept arguments.
Using AltF2 with GNOME
GNOME command entry dialog box
Figure 1.1.  Using Alt+F2 with GNOME

Using AltF2 with KDE
KDE command entry dialog box, which also searches menu items, command history, and open applications.
Figure 1.2.  Using Alt+F2 with KDE

Using AltF2 with LXDE
LXDE command entry dialog box.
Figure 1.3.  Using Alt+F2 with LXDE

Using AltF2 with MATE
MATE command entry dialog box.
Figure 1.4.  Using Alt+F2 with MATE

Using AltF2 with XFCE
XFCE command entry dialog box.
Figure 1.5.  Using Alt+F2 with XFCE

1.3. Launching applications from the Desktop Menu

Applications can also be opened from the menu system provided by the desktop environment in use. While the presentation may vary between desktop environments, the menu entries and their categories are provided by the individual application and standardized by the freedesktop.org Desktop Menu Specification. Some desktop environments also provide search functionality in their menu system to allow quick and easy access to applications.

1.3.1. Using GNOME menus

The GNOME menu, called the overview, can be accessed by either clicking the Activities button in the top left of the primary display, by moving the mouse past the top left hot corner, or by pressing the Super ( Windows ) key. The overview presents documents in addition to applications.
Selecting an item from the menu is best accomplished using the search box. Simply bring up the overview, and begin typing the name of the application you want to launch. Pressing enter will launch the highlighted application, or you can use the arrow keys or mouse to choose an alternative.
Using the GNOME search box
Typing the name of an application into the overview search box will display matching menu entries. The search also matches descriptions, so that typing browser will display installed browsers.
Figure 1.6.  Using the GNOME search box

The overview can also be browsed. The bar on the left, called the dash, shows frequently used applications and a grid icon. Clicking on the grid icon brings up a grid in the center of the window that displays frequently used applications. The grid will display all available applications if selected using the All button at the bottom of the screen.
Browsing GNOME menu entries
The GNOME menu has a bar on the left for frequently used applications, which includes a grid icon that brings up a grid in the center of the window. Users can then use the buttons at the bottom of the screen to display either a larger list of frequently used applications, or to view all available applications.
Figure 1.7.  Browsing GNOME menu entries

To learn more about using GNOME shell, visit https://wiki.gnome.org/GnomeShell/CheatSheet

1.3.2.  Using KDE menus

The KDE menu is opened by clicking the Fedora button at the bottom left corner of the screen. The menu initially displays favorite applications, which can be added to by right clicking any menu entry. Hovering over the icons in the lower portion of the menu will display applications, file systems, recently used applications, or options for logging out of the system.
The KDE desktop menu.
The KDE menu displays applications in categories. The contents of the categories are displayed when clicked.
Figure 1.8.  The KDE desktop menu.

Search functionality is also available in the KDE menu system. To search for applications, open the menu and begin typing. The menu will display matching entries.
Searching with the KDE menu.
The KDE menu will search for matching applications if you type into the search box. For example, typing browser will display installed browsers and other matching entries.
Figure 1.9.  Searching with the KDE menu.

1.3.3. Using menus in LXDE, MATE, and XFCE

Menus in LXDE, MATE, and XFCE have a varied appearance but a very similar structure. They categorize applications, and the contents of a category are displayed by hovering the cursor over the entry. Applications are launched by clicking on an entry.
The LXDE menu
LXDE Menu
Figure 1.10.  The LXDE menu

MATE menu
MATE menu
Figure 1.11.  MATE menu

XFCE Menu
XFCE Menu
Figure 1.12.  XFCE Menu

Chapter 2. 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 Fedora Installation Guide.

2.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 2.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 2.1. Options configurable in /etc/locale.conf
Option Description
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.

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

2.1.2. Listing Available Locales

To list all locales available for your system, type:
localectl list-locales
Example 2.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

2.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 2.1, “Options configurable in /etc/locale.conf”.
Example 2.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

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

2.2.1. Displaying the Current Settings

As mentioned before, you can check your current keyboard layout configuration with the following command:
localectl status
Example 2.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

2.2.2. Listing Available Keymaps

To list all available keyboard layouts that can be configured on your system, type:
localectl list-keymaps
Example 2.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


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

2.3. Additional Resources

For more information on how to configure the keyboard layout on Fedora, 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.

Chapter 3. 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.
Fedora 24 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 Fedora 24 and is part of systemd; the traditional date command; and the hwclock utility for accessing the hardware clock.

3.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 3.2, “Using the date Command”.

3.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 3.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 2013-09-16 19:30:24 CEST
  Universal time: Mon 2013-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 2013-03-31 01:59:59 CET
                  Sun 2013-03-31 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2013-10-27 02:59:59 CEST
                  Sun 2013-10-27 02:00:00 CET

3.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 3.1.5, “Synchronizing the System Clock with a Remote Server” to temporally disable the service.
Example 3.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.

3.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 3.3. Changing the Current Date
To change the current date to 2 June 2013 and keep the current time (11:26 p.m.), run the following command as root:
~]# timedatectl set-time "2013-06-02 23:26:00"

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

3.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 3.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 14.3.1, “Installing chrony” for more information.

3.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 3.1, “Using the timedatectl Command”.

3.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 3.6, “Displaying the Current Date and Time”. See Table 3.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 3.1. Commonly Used Control Sequences
Control Sequence Description
%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, 2013).
%Z The time zone abbreviation (for example, CEST).
%F The full date in the YYYY-MM-DD format (for example, 2013-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 3.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 2013
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 2013
To customize the output of the date command, type:
~]$ date +"%Y-%m-%d %H:%M"
2013-09-16 17:30

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

3.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 3.8. Changing the Current Date
To change the current date to 2 June 2013 and keep the current time (11:26 p.m.), run the following command as root:
~]# date --set 2013-06-02 23:26:00

3.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 Fedora 6, the hwclock command was run automatically on every system shutdown or reboot, but it is not in Fedora 24. 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 14, Configuring NTP Using the chrony Suite and Chapter 15, Configuring NTP Using ntpd. For information about PTP, see Chapter 16, Configuring PTP Using ptp4l. For information about setting the hardware clock after executing ntpdate, see Section 15.18, “Configuring the Hardware Clock Update”.

3.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 3.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 2014 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 3.1.4, “Changing the Time Zone”.

3.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 3.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, 2014", and keep the hardware clock in UTC, run the command as root in the following format:
~]# hwclock --set --date "21 Oct 2014 21:17" --utc

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

3.4. Additional Resources

For more information on how to configure the date and time in Fedora 24, 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 4. Managing Users and Groups

The control of users and groups is a core element of Fedora 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.

4.1. Introduction to Users and Groups

While users can be either people (meaning accounts tied to physical users) or accounts which 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, Fedora 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 the Access Control Lists chapter of the Storage Administration Guide.

4.1.1. User Private Groups

Fedora uses a user private group (UPG) scheme, which makes UNIX groups easier to manage. A user private group is created whenever a new user is added to the system. It has the same name as the user for which it was created and that user is the only member of the user private group.
User private groups make it safe to set default permissions for a newly created file or directory, allowing both the user and the group of that user to make modifications to the file or directory.
The setting which determines what permissions are applied to a newly created file or directory is called a umask and is configured in the /etc/bashrc file. Traditionally on UNIX-based systems, the umask is set to 022, which allows only the user who created the file or directory to make modifications. Under this scheme, all other users, including members of the creator's group, are not allowed to make any modifications. However, under the UPG scheme, this group protection is not necessary since every user has their own private group.
A list of all groups is stored in the /etc/group configuration file.

4.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 the /etc/login.defs file to enforce security policies.
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.

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

4.2.1. Using the Users Settings Tool

Press the Super key to enter the Activities Overview, type Users and then press Enter. The Users settings tool appears. The Super key appears in a variety of guises, depending on the keyboard and other hardware, but often as either the Windows or Command key, and typically to the left of the Spacebar.
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
The Users settings tool
Figure 4.1. The Users Settings Tool

When a new user is created, the account is disabled until a password is set. The Add User menu contains the options to set a password by the administrator immediately, or to allow the user to choose a password at the first login.

4.3. Using Command Line Tools

Apart from the Users settings tool described in Section 4.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 4.1, “Command line utilities for managing users and groups”.
Table 4.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 Standard utility for administering the /etc/group configuration file.
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.

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

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

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 Fedora, UIDs below 1000 are reserved for system use and should not be assigned to users.
    • A GID greater than 999 is created. Under Fedora, GIDs below 1000 are reserved for system use and should not be assigned to users.
    • The optional GECOS information is left blank. The GECOS field can be used to provide additional information about the user, such as their full name or phone number.
    • The home directory for juan is set to /home/juan/.
    • The default shell is set to /bin/bash.
  2. A new line for juan is created in /etc/shadow:
    juan:!!:14798:0:99999:7:::
    The line has the following characteristics:
    • It begins with the username juan.
    • Two exclamation marks (!!) appear in the password field of the /etc/shadow file, which locks the account.

      Note

      If an encrypted password is passed using the -p flag, it is placed in the /etc/shadow file on the new line for the user.
    • The password is set to never expire.
  3. A new line for a group named juan is created in /etc/group:
    juan:x:1001:
    A group with the same name as a user is called a user private group. For more information on user private groups, see Section 4.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. The contents of /etc/skel/ may vary depending on installed applications:
    ~]# ls -la /home/juan
    total 24
    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 Jul 09 08:43 .bash_logout
    -rw-r--r--. 1 juan juan  176 Jul 09 08:43 .bash_profile
    -rw-r--r--. 1 juan juan  124 Jul 09 08:43 .bashrc
    drwxr-xr-x. 4 juan juan 4096 Jul 09 08:43 .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.

4.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 4.3, “Common groupadd command-line options”.
Table 4.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.

4.3.3. Enabling Password Aging

For security reasons, it is advisable to require users to change their passwords periodically. This can be done by using the chage command.

Shadow passwords must be enabled to use chage

Shadow passwords must be enabled to use the chage command. For more information, see Section 4.1.2, “Shadow Passwords”.
To configure password expiration for a user from a shell prompt, run the following command as root:
chage [options] username
…where options are command line options as described in Table 4.4, “chage command line options”. When the chage command is followed directly by a username (that is, when no command line options are specified), it displays the current password aging values and allows you to change them interactively.
Table 4.4. chage command line options
Option Description
-d days Specifies the number of days since January 1, 1970 the password was changed.
-E date Specifies the date on which the account is locked, in the format YYYY-MM-DD. Instead of the date, the number of days since January 1, 1970 can also be used.
-I days Specifies the number of inactive days after the password expiration before locking the account. If the value is 0, the account is not locked after the password expires.
-l Lists current account aging settings.
-m days Specify the minimum number of days after which the user must change passwords. If the value is 0, the password does not expire.
-M days Specify the maximum number of days for which the password is valid. When the number of days specified by this option plus the number of days specified with the -d option is less than the current day, the user must change passwords before using the account.
-W days Specifies the number of days before the password expiration date to warn the user.

You can configure a password to expire the first time a user logs in. This forces users to change passwords immediately.
  1. Set up an initial password. There are two common approaches to this step: you can either assign a default password, or you can use a null password.
    To assign a default password, type the following at a shell prompt as root:
    passwd username
    To assign a null password instead, use the following command:
    passwd -d username

    Avoid using null passwords whenever possible

    Using a null password, while convenient, is a highly insecure practice, as any third party can log in first and access the system using the insecure username. Always make sure that the user is ready to log in before unlocking an account with a null password.
  2. Force immediate password expiration by running the following command as root:
    chage -d 0 username
    This command sets the value for the date the password was last changed to the epoch (January 1, 1970). This value forces immediate password expiration no matter what password aging policy, if any, is in place.
Upon the initial log in, the user is now prompted for a new password.

4.3.4. Enabling Automatic Logouts

Especially when the user is logged in as root, an unattended login session may pose a significant security risk. To reduce this risk, you can configure the system to automatically log out idle users after a fixed period of time:
  1. Make sure the screen package is installed. You can do so by running the following command as root:
    dnf install screen
    For more information on how to install packages in Fedora, refer to Section 6.2.4, “Installing Packages”.
  2. As root, add the following line at the beginning of the /etc/profile file to make sure the processing of this file cannot be interrupted:
    trap "" 1 2 3 15
  3. Add the following lines at the end of the /etc/profile file to start a screen session each time a user logs in to a virtual console or remotely:
    SCREENEXEC="screen"
    if [ -w $(tty) ]; then
      trap "exec $SCREENEXEC" 1 2 3 15
      echo -n 'Starting session in 10 seconds'
      sleep 10
      exec $SCREENEXEC
    fi
    Note that each time a new session starts, a message will be displayed and the user will have to wait ten seconds. To adjust the time to wait before starting a session, change the value after the sleep command.
  4. Add the following lines to the /etc/screenrc configuration file to close the screen session after a given period of inactivity:
    idle 120 quit
    autodetach off
    This will set the time limit to 120 seconds. To adjust this limit, change the value after the idle directive.
    Alternatively, you can configure the system to only lock the session by using the following lines instead:
    idle 120 lockscreen
    autodetach off
    This way, a password will be required to unlock the session.
The changes take effect the next time a user logs in to the system.

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

4.4. Additional Resources

For more information on how to manage users and groups on Fedora, 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.
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.

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 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-hand pane.
  4. Change the Account Type from Standard to Administrator. This will add the user to the wheel group.
See Section 4.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 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
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=/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 sudoer's 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 their 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 a sudoer's 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

See Also

Part II. Package Management

Chapter 6. DNF

DNF is the The Fedora Project package manager that is able to query for information about packages, fetch packages from repositories, install and uninstall packages using automatic dependency resolution, and update an entire system to the latest available packages. DNF performs automatic dependency resolution on packages you are updating, installing or removing, and thus is able to automatically determine, fetch and install all available dependent packages. DNF can be configured with new, additional repositories, or package sources, and also provides many plug-ins which enhance and extend its capabilities. DNF is able to perform many of the same tasks that RPM can; additionally, many of the command line options are similar. DNF enables easy and simple package management on a single machine or on groups of them.

Secure package management with GPG-signed packages

DNF 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, DNF 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 The Fedora Project, and were not modified during transfer. See Section 6.3, “Configuring DNF and DNF Repositories” for details on enabling signature-checking with DNF, or Section A.3.2, “Checking Package Signatures” for information on working with and verifying GPG-signed RPM packages in general.
DNF also enables you to easily set up your own repositories of RPM packages for download and installation on other machines.
Learning DNF 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.

DNF and superuser privileges

You must have superuser privileges in order to use the dnf command 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.

6.1. Checking For and Updating Packages

6.1.1. Checking For Updates

The quickest way to check for updates is to attempt to install any available updates by using the dnf upgrade command as follows:
~]# dnf upgrade
Last metadata expiration check performed 1:24:32 ago on Thu May 14 23:23:51 2015.
Dependencies resolved.
Nothing to do.
Complete!
Note that dnf upgrade installs only those updates that can be installed. If a package cannot be updated, because of dependency problems for example, it is skipped.
The dnf check-update command can be used see which installed packages on your system have new versions available, however it does not mean that they can be successfully installed. This command is therefore mostly useful in scripts and for checking for updated packages that were not installed after running dnf upgrade.
For example:
~]# dnf check-update
Using metadata from Mon Apr 20 16:34:10 2015 (2:42:10 hours old)

python.x86_64                     2.7.9-6.fc22          updates
python-cryptography.x86_64        0.8.2-1.fc22          updates
python-libs.x86_64                2.7.9-6.fc22          updates
The packages in the above output are listed as having updated versions. The line in the example output tells us:
  • python — the name of the package,
  • x86_64 — the CPU architecture the package was built for,
  • 2.7.9 — the version of the updated package,
  • 6.fc22 — the release of the updated package,
  • updates-testing — the repository in which the updated package is located.

6.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:
dnf upgrade package_name
For example, to update the python package, type:
~]# dnf upgrade python
Using metadata from Mon Apr 20 16:38:16 2015 (2:42:14 hours old)
Dependencies resolved.
==================================================================
 Package       Arch       Version       Repository       Size
==================================================================
Upgrading:
 python        x86_64     2.7.9-6.fc22  updates           92 k
 python-libs   x86_64     2.7.9-6.fc22  updates          5.8 M

Transaction Summary
==================================================================
Upgrade  2 Packages

Total download size: 5.9 M
Is this ok [y/N]:
This output contains:
  1. python.x86_64 — you can download and install new python package.
  2. python-libs.x86_64 — DNF has resolved that the python-libs-2.7.9-6.fc22.x86_64 package is a required dependency of the python package.
  3. DNF presents the update information and then prompts you as to whether you want it to perform the update; DNF runs interactively by default. If you already know which transactions DNF plans to perform, you can use the -y option to automatically answer yes to any questions DNF may ask (in which case it runs non-interactively). However, you should always examine which changes DNF plans to make to the system so that you can easily troubleshoot any problems that might arise.
    If a transaction does go awry, you can view DNF's transaction history by using the dnf history command as described in Section 6.2.6, “Working with Transaction History”.

Updating and installing kernels with DNF

DNF always installs a new kernel in the same sense that RPM installs a new kernel when you use the command rpm -i kernel. Therefore, you do not need to worry about the distinction between installing and upgrading a kernel package when you use the dnf command: it will do the right thing, regardless of whether you are using the dnf upgrade or dnf 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 updating kernels with RPM.

Updating All Packages and Their Dependencies

To update all packages and their dependencies, enter dnf upgrade without any arguments:
dnf upgrade

6.1.3. Preserving Configuration File Changes

You will inevitably make changes to the configuration files installed by packages as you use your Fedora system. RPM, which DNF 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.

6.2. Packages and Package Groups

6.2.1. Searching Packages

You can search all RPM package names and summaries by using the following command:
dnf search term
Add the all to match against descriptions and URLs.
dnf search all term
This command displays the list of matches for each term. For example, to list all packages that match meld or kompare, type:
~]# dnf search meld kompare
Loaded plugins: langpacks, presto, refresh-packagekit
============================== N/S Matched: meld ===============================
meld.noarch : Visual diff and merge tool
python-meld3.x86_64 : HTML/XML templating system for Python

============================= N/S Matched: kompare =============================
komparator.x86_64 : Kompare and merge two folders

  Name and summary matches only, use "search all" for everything.

6.2.2. Listing Packages

dnf list and related commands provide information about packages, package groups, and repositories.
All of DNF'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 multiple times) and ? (which expands to match any one character).

Filtering results with glob expressions

Be careful to escape the glob expressions when passing them as arguments to a dnf command, otherwise the Bash shell will interpret these expressions as pathname expansions, and potentially pass all files in the current directory that match the globs to DNF. To make sure the glob expressions are passed to DNF as intended, either:
  • escape the wildcard characters by preceding them with a backslash character; or,
  • double-quote or single-quote the entire glob expression.
DNF searches only package names when using glob expressions. To search for a version of a package, include a dash and part of the version number as follows:
~]# dnf search kernel*-4*
Last metadata expiration check performed 2:46:09 ago on Thu May 14 23:23:51 2015.
Installed Packages
kernel.x86_64                        4.0.0-1.fc22                     @System
kernel.x86_64                        4.0.2-300.fc22                   @System
kernel-core.x86_64                   4.0.0-1.fc22                     @System
kernel-core.x86_64                   4.0.2-300.fc22                   @System
[output truncated]
dnf list glob_expression
Lists information on installed and available packages matching all glob expressions.
Example 6.1. Listing all ABRT addons and plug-ins using glob expressions
Packages with various ABRT addons and plug-ins either begin with abrt-addon-, or abrt-plugin-. To list these packages, type the following at a shell prompt:
~]# dnf list abrt-addon\* abrt-plugin\*
Last metadata expiration check performed 0:14:36 ago on Mon May 25 23:38:13 2015.
Installed Packages
abrt-addon-ccpp.x86_64                  2.5.1-2.fc22               @System
abrt-addon-coredump-helper.x86_64       2.5.1-2.fc22               @System
abrt-addon-kerneloops.x86_64            2.5.1-2.fc22               @System
abrt-addon-pstoreoops.x86_64            2.5.1-2.fc22               @System
abrt-addon-python.x86_64                2.5.1-2.fc22               @System
abrt-addon-python3.x86_64               2.5.1-2.fc22               @System
abrt-addon-vmcore.x86_64                2.5.1-2.fc22               @System
abrt-addon-xorg.x86_64                  2.5.1-2.fc22               @System
abrt-plugin-bodhi.x86_64                2.5.1-2.fc22               @System
Available Packages
abrt-addon-upload-watch.x86_64          2.5.1-2.fc22               fedora

dnf list all
Lists all installed and available packages.
Example 6.2. Listing all installed and available packages
~]# dnf list all
Last metadata expiration check performed 0:21:11 ago on Mon May 25 23:38:13 2015.
Installed Packages
NetworkManager.x86_64                   1:1.0.2-1.fc22             @System
NetworkManager-libnm.x86_64             1:1.0.2-1.fc22             @System
PackageKit.x86_64                       1.0.6-4.fc22               @System
PackageKit-glib.x86_64                  1.0.6-4.fc22               @System
aajohan-comfortaa-fonts.noarch          2.004-4.fc22               @System
abrt.x86_64                             2.5.1-2.fc22               @System
[output truncated]

dnf list installed
Lists all packages installed on your system. The rightmost column in the output lists the repository from which the package was retrieved.
Example 6.3. Listing installed packages using a double-quoted glob expression
To list all installed packages that begin with krb followed by exactly one character and a hyphen, type:
~]# dnf list installed "krb?-*"
Last metadata expiration check performed 0:34:45 ago on Mon May 25 23:38:13 2015.
Installed Packages
krb5-libs.x86_64                        1.13.1-3.fc22              @System
krb5-workstation.x86_64                 1.13.1-3.fc22              @System

dnf list available
Lists all available packages in all enabled repositories.
Example 6.4. Listing available packages using a single glob expression with escaped wildcard characters
To list all available packages with names that contain gstreamer and then plugin, run the following command:
~]# dnf list available gstreamer\*plugin\*
Last metadata expiration check performed 0:42:15 ago on Mon May 25 23:38:13 2015.
Available Packages
gstreamer-plugin-crystalhd.i686              3.10.0-8.fc22          fedora
gstreamer-plugin-crystalhd.x86_64            3.10.0-8.fc22          fedora
gstreamer-plugins-bad-free.i686              0.10.23-24.fc22        fedora
gstreamer-plugins-bad-free.x86_64            0.10.23-24.fc22        fedora
gstreamer-plugins-bad-free-devel.i686        0.10.23-24.fc22        fedora
gstreamer-plugins-bad-free-devel.x86_64      0.10.23-24.fc22        fedora
 [output truncated]

dnf group list
Lists all package groups.
Example 6.5. Listing all package groups
~]# dnf group list
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Group Process
Installed Groups:
   Administration Tools
   Design Suite
   Dial-up Networking Support
   Fonts
   GNOME Desktop Environment
[output truncated]

dnf repolist
Lists the repository ID, name, and number of packages it provides for each enabled repository.
Example 6.6. Listing enabled repositories
~]# dnf repolist
Last metadata expiration check performed 0:48:29 ago on Mon May 25 23:38:13 2015.
repo id                             repo name                           status
*fedora                             Fedora 22 - x86_64                  44,762
*updates                            Fedora 22 - x86_64 - Updates             0

dnf repository-packages repo_id list
Lists the packages from the specified repository.
Example 6.7. Listing packages from a single repository
~]# dnf repository-packages fedora list [option]
Last metadata expiration check performed 1:38:25 ago on Wed May 20 22:16:16 2015.
Installed Packages
PackageKit.x86_64                        1.0.6-3.fc22                    @System
PackageKit-glib.x86_64                   1.0.6-3.fc22                    @System
aajohan-comfortaa-fonts.noarch           2.004-4.fc22                    @System
[output truncated]
The default action is to list all packages available and installed from the repository specified. Add the available or installed option to list only those packages available or installed from the specified repository.

6.2.3. Displaying Package Information

To display information about one or more packages, use a command as follows:
dnf info package_name
For example, to display information about the abrt package, type:
~]# dnf info abrt
Last metadata expiration check performed 5 days, 1:12:55 ago on Wed May 20 22:16:16 2015.
Installed Packages
Name        : abrt
Arch        : x86_64
Epoch       : 0
Version     : 2.5.1
Release     : 2.fc22
Size        : 2.1 M
Repo        : @System
From repo   : updates-testing
Summary     : Automatic bug detection and reporting tool
URL         : https://github.com/abrt/abrt/wiki/ABRT-Project
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 dnf info package_name command is similar to the rpm -q --info package_name command, but provides as additional information the name of the DNF repository the RPM package was installed from (look for the From repo: line in the output). The dnf info command shows only the newest available package if there is a newer version available than the one installed. The dnf repoquery command can show all installed and available packages.
To display information about all available packages, both installed and available from a repository, use a command as follows:
dnf repoquery package_name --info
For example, to display information about the abrt package, type:
~]# dnf repoquery abrt --info
Last metadata expiration check: 1:01:44 ago on Tue May 31 06:51:51 2016.
Name        : abrt
Version     : 2.8.1
Release     : 1.fc24
Architecture: x86_64
Size        : 2318452
License     : GPLv2+
Source RPM  : abrt-2.8.1-1.fc24.src.rpm
Build Date  : 2016-05-25 08:54
Packager    : Fedora Project
URL         : https://abrt.readthedocs.org/
Summary     : Automatic bug detection and reporting tool
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.
See the dnf repoquery usage statement for more options:
~]$ dnf repoquery -h
usage: dnf [options] COMMAND
output truncated

6.2.4. Installing Packages

DNF allows you to install both a single package and multiple packages, as well as a package group of your choice.

Installing Individual Packages

To install a single package and all of its non-installed dependencies, enter a command in the following form:
dnf install package_name
You can also install multiple packages simultaneously by appending their names as arguments:
dnf install package_name package_name
If you are installing packages on a multilib system, such as an AMD64 or Intel64 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. For example, to install the sqlite2 package for i586, type:
~]# dnf install sqlite2.i586
You can use glob expressions to quickly install multiple similarly-named packages:
~]# dnf install audacious-plugins-\*
In addition to package names and glob expressions, you can also provide file names to dnf install. If you know the name of the binary you want to install, but not its package name, you can give dnf install the path name:
~]# dnf install /usr/sbin/named
dnf 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.

Finding which package owns a file

If you know you want to install the package that contains the named binary, but you do not know in which /usr/bin or /usr/sbin directory the file is installed, use the dnf provides command with a glob expression:
~]# dnf provides "*bin/named"
Using metadata from Thu Apr 16 13:41:45 2015 (4:23:50 hours old)
bind-32:9.10.2-1.fc22.x86_64 : The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server
Repo        : @System
dnf provides "*/file_name" will find all the packages that contain file_name.

Installing a Package Group

A package group is similar to a package: it is not useful by itself, but installing one pulls a group of dependent packages that serve a common purpose. A package group has a name and a groupid (GID). The dnf group list -v command lists the names of all package groups, and, next to each of them, their groupid in parentheses. The groupid is always the term in the last pair of parentheses, such as kde-desktop-environment in the following example:
~]# dnf -v group list kde\*
cachedir: /var/cache/dnf/x86_64/22
Loaded plugins: builddep, config-manager, copr, playground, debuginfo-install, download, generate_completion_cache, kickstart, needs-restarting, noroot, protected_packages, Query, reposync, langpacks
initialized Langpacks plugin
DNF version: 0.6.5
repo: using cache for: fedora
not found deltainfo for: Fedora 22 - x86_64
not found updateinfo for: Fedora 22 - x86_64
repo: using cache for: updates-testing
repo: using cache for: updates
not found updateinfo for: Fedora 22 - x86_64 - Updates
Using metadata from Thu Apr 16 13:41:45 2015 (4:37:51 hours old)
Available environment groups:
   KDE Plasma Workspaces (kde-desktop-environment)
You can install a package group by passing its full group name (without the groupid part) to group install:
dnf group install group_name
Multi-word names must be quoted.
You can also install by groupid:
dnf group install groupid
You can even pass the groupid, or quoted name, to the install command if you prepend it with an @-symbol (which tells dnf that you want to perform a group install):
dnf install @group
For example, the following are alternative but equivalent ways of installing the KDE Plasma Workspaces group:
~]# dnf group install "KDE Plasma Workspaces"
~]# dnf group install kde-desktop-environment
~]# dnf install @kde-desktop-environment

6.2.5. Removing Packages

Similarly to package installation, DNF allows you to uninstall (remove in RPM and DNF terminology) both individual packages and a package group.

Removing Individual Packages

To uninstall a particular package, as well as any packages that depend on it, run the following command as root:
dnf remove package_name
As when you install multiple packages, you can remove several at once by adding more package names to the command. For example, to remove totem, rhythmbox, and sound-juicer, type the following at a shell prompt:
~]# dnf remove totem rhythmbox sound-juicer
Similar to install, remove can take these arguments:
  • package names
  • glob expressions
  • file lists
  • package provides

Removing a package when other packages depend on it

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

Removing a Package Group

You can remove a package group using syntax congruent with the install syntax:
dnf group remove group
dnf remove @group
The following are alternative but equivalent ways of removing the KDE Plasma Workspaces group:
~]# dnf group remove "KDE Plasma Workspaces"
~]# dnf group remove kde-desktop-environment
~]# dnf remove @kde-desktop-environment

6.2.6. Working with Transaction History

The dnf history command allows users to review information about a timeline of DNF transactions, the dates and times on when they occurred, the number of packages affected, whether 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.

Listing Transactions

To display a list of all transactions, as root, either run dnf history with no additional arguments, or enter the following command:
dnf history list
To display only transactions in a given range, use the command in the following form:
dnf 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:
dnf history list glob_expression
For example, the list of first five transactions may look as follows:
~]# dnf history list 1..4
Using metadata from Thu Apr 16 13:41:45 2015 (5:47:31 hours old)
ID     | Login user               | Date a | Action | Altere
-------------------------------------------------------------------------------
     4 | root <root>              | 2015-04-16 18:35 | Erase          |    1
     3 | root <root>              | 2015-04-16 18:34 | Install        |    1
     2 | root <root>              | 2015-04-16 17:53 | Install        |    1
     1 | System <unset>           | 2015-04-16 14:14 | Install        |  668 E
The dnf history list command produces 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, however sometimes the command used to perform the transaction is displayed. 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 6.1, “Possible values of the Action(s) field”.
  • Altered — the number of packages that were affected by a transaction, possibly followed by additional information.
Table 6.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.

Reverting and Repeating Transactions

Apart from reviewing the transaction history, the dnf history command provides means to revert or repeat a selected transaction. To revert a transaction, type the following at a shell prompt as root:
dnf history undo id
To repeat a particular transaction, as root, run the following command:
dnf history redo id
Both commands also accept the last keyword to undo or repeat the latest transaction.
Note that both dnf history undo and dnf history redo commands merely revert or repeat the steps that were performed during a transaction, and will fail if the required packages are not available. For example, if the transaction installed a new package, the dnf history undo command will uninstall it and also attempt to downgrade all updated packages to their previous version, but the command will fail if the required packages are not available.

6.3. Configuring DNF and DNF Repositories

The configuration file for DNF and related utilities is located at /etc/dnf/dnf.conf. This file contains one mandatory [main] section, which allows you to set DNF options that have global effect, and may 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/dnf/dnf.conf file override values set in the [main] section.
This section shows you how to:
  • set global DNF options by editing the [main] section of the /etc/dnf/dnf.conf configuration file;
  • set options for individual repositories by editing the [repository] sections in /etc/dnf/dnf.conf and .repo files in the /etc/yum.repos.d/ directory;
  • use DNF variables in /etc/dnf/dnf.conf and files in the /etc/yum.repos.d/ directory so that dynamic version and architecture values are handled correctly;
  • add, enable, and disable DNF repositories on the command line; and,
  • set up your own custom DNF repository.

6.3.1. Setting [main] Options

The /etc/dnf/dnf.conf configuration file contains exactly one [main] section, and while some of the key-value pairs in this section affect how dnf operates, others affect how DNF treats repositories. You can add many additional options under the [main] section heading in /etc/dnf/dnf.conf.
A sample /etc/dnf/dnf.conf configuration file can look like this:
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=true
The following are the most commonly-used options in the [main] section:
debuglevel=value
…where value is an integer between 0 and 10. Setting a higher debuglevel value causes dnf to display more detailed debugging output. debuglevel=0 disables debugging output, and debuglevel=2 is the default.
exclude=package_name [more_package_names]
This option allows you to exclude packages by keyword during installation and updates. Listing multiple packages for exclusion can be accomplished by quoting a space-delimited list of packages. Shell globs using wildcards (for example, * and ?) are allowed.
gpgcheck=value
…where value is one of:
0 — Disable GPG signature-checking on packages in all repositories, including local package installation.
1 — Enable GPG signature-checking on all packages in all repositories, including local package installation. gpgcheck=1 is the default, and thus all packages' signatures are checked.
If this option is set in the [main] section of the /etc/dnf/dnf.conf file, it sets the GPG-checking rule for all repositories. However, you can also set gpgcheck=value for individual repositories instead; 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/dnf/dnf.conf.
For more information on GPG signature-checking, refer to Section A.3.2, “Checking Package Signatures”.
installonlypkgs=space separated list of packages
Here you can provide a space-separated list of packages which dnf can install, but will never update. See the dnf.conf(5) manual page for the list of packages which are install-only by default.
If you add the installonlypkgs directive to /etc/dnf/dnf.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 dnf.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
…where value is an integer representing the maximum number of versions that can be installed simultaneously for any single package listed in the installonlypkgs directive.
The defaults for the installonlypkgs directive include several different kernel packages, so be aware that changing the value of installonly_limit will also affect the maximum number of installed versions of any single kernel package. The default value listed in /etc/dnf/dnf.conf is installonly_limit=3, and it is not recommended to decrease this value, particularly below 2.
keepcache=value
…where value is one of:
0 — Do not retain the cache of headers and packages after a successful installation. This is the default.
1 — Retain the cache after a successful installation.
For a complete list of available [main] options, refer to the [MAIN] OPTIONS section of the dnf.conf(5) manual page.

6.3.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 DNF 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
…where repository_name is a human-readable string describing the repository.
parameter=repository_url
…where parameter is one of the following: baseurl, metalink, or mirrorlist;
…where repository_url is a URL to a directory containing a repodata directory of a repository, a metalink file, or a mirror list file.
  • 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 username 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 DNF always expands the $releasever, $arch, and $basearch variables in URLs. For more information about DNF variables, refer to Section 6.3.3, “Using DNF Variables”.
To configure the default set of repositories, use the enabled option as follows:
enabled=value
…where value is one of:
0 — Do not include this repository as a package source when performing updates and installs.
1 — Include this repository as a package source.
Turning repositories on and off can also be performed by passing either the --set-enabled repo_name or --set-disabled repo_name option to the dnf command, or through the Add/Remove Software window of the PackageKit utility.
Many more [repository] options exist. For a complete list, refer to the [repository] OPTIONS section of the dnf.conf(5) manual page.

6.3.3. Using DNF Variables

Variables can be used only in the appropriate sections of the DNF configuration files, namely the /etc/dnf/dnf.conf file and all .repo files in the /etc/yum.repos.d/ directory. Repository variables include:
$releasever
Refers to the release version of operating system which DNF derives from information available in RPMDB.
$arch
Refers to the system’s CPU architecture. Valid values for $arch include: i586, i686 and x86_64.
$basearch
Refers to the base architecture of the system. For example, i686 and i586 machines both have a base architecture of i386, and AMD64 and Intel64 machines have a base architecture of x86_64.

6.4. Viewing the Current Configuration

To list all configuration options and their corresponding values, and the repositories, execute the dnf config-manager command with the --dump option:
~]$ dnf config-manager --dump
=============================== main ======================================
[main]
alwaysprompt = True
assumeno = False
assumeyes = False
bandwidth = 0
best = False
bugtracker_url = https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dnf
cachedir = /var/cache/dnf/x86_64/22
[output truncated]

6.5. Adding, Enabling, and Disabling a DNF Repository

Section 6.3.2, “Setting [repository] Options” describes various options you can use to define a DNF repository. This section explains how to add, enable, and disable a repository by using the dnf config-manager command.

Adding a DNF Repository

To define a new repository, you can either add a [repository] section to the /etc/dnf/dnf.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 DNF, and it is recommended to define your repositories here instead of in /etc/dnf/dnf.conf.
DNF repositories commonly provide their own .repo file. To add such a repository to your system and enable it, run the following command as root:
dnf config-manager --add-repo repository_url
…where repository_url is a link to the .repo file.
Example 6.8. Adding example.repo
To add a repository located at http://www.example.com/example.repo, type the following at a shell prompt:
~]# dnf config-manager --add-repo http://www.example.com/example.repo
adding repo from: http://www.example.com/example.repo

Enabling a DNF Repository

To enable a particular repository or repositories, type the following at a shell prompt as root:
dnf config-manager --set-enabled repository
…where repository is the unique repository ID. To display the current configuration, add the --dump option.

Disabling a DNF Repository

To disable a DNF repository, run the following command as root:
dnf config-manager --set-disabled repository
…where repository is the unique repository ID. To display the current configuration, add the --dump option.

6.6. Additional Resources

Installed Documentation

  • dnf(8) — The DNF command reference manual page.
  • dnf.conf(8) — DNF Configuration Reference manual page.

Online Documentation

http://dnf.readthedocs.org/en/latest/index.html
The DNF wiki contains more documentation.

Part III. Infrastructure Services

This part provides information on how to configure services and daemons, configure authentication, and enable remote logins.

Chapter 7. Services and Daemons

Maintaining security on your system is extremely important, and one approach for this task is to manage access to system services carefully. Your system may need to provide open access to particular services (for example, httpd if you are running a web server). However, if you do not need to provide a service, you should turn it off to minimize your exposure to possible bug exploits.
This chapter covers the configuration of the services to be run when a system is started, and provides information on how to start, stop, and restart the services on the command line using the systemctl utility.

Keep the system secure

When you allow access for new services, always remember that both the firewall and SELinux need to be configured as well. One of the most common mistakes committed when configuring a new service is neglecting to implement the necessary firewall configuration and SELinux policies to allow access for it. For more information, refer to the Fedora 24 Security Guide.

7.1. Configuring Services

To allow you to configure which services are started at boot time, Fedora is shipped with the systemctl command line tool.

Do not use the ntsysv and chkconfig utilities

Although it is still possible to use the ntsysv and chkconfig utilities to manage services that have init scripts installed in the /etc/rc.d/init.d/ directory, it is advised that you use the systemctl utility.

Enabling the irqbalance service

To ensure optimal performance on POWER architecture, it is recommended that the irqbalance service is enabled. In most cases, this service is installed and configured to run during the Fedora 24 installation. To verify that irqbalance is running, type the following at a shell prompt:
systemctl status irqbalance.service

7.1.1. Enabling the Service

To configure a service to be automatically started at boot time, use the systemctl command in the following form:
systemctl enable service_name.service
The service will be started the next time you boot the system. For information on how to start the service immediately, refer to Section 7.2.2, “Running the Service”.
Example 7.1. Enabling the httpd service
Imagine you want to run the Apache HTTP Server on your system. Provided that you have the httpd package installed, you can enable the httpd service by typing the following at a shell prompt as root:
~]# systemctl enable httpd.service

7.1.2. Disabling the Service

To disable starting a service at boot time, use the systemctl command in the following form:
systemctl disable service_name.service
The next time you boot the system, the service will not be started. For information on how to stop the service immediately, refer to Section 7.2.3, “Stopping the Service”.
Example 7.2. Disabling the telnet service
In order to secure the system, users are advised to disable insecure connection protocols such as Telnet. You can make sure that the telnet service is disabled by running the following command as root:
~]# systemctl disable telnet.service

7.2. Running Services

The systemctl utility also allows you to determine the status of a particular service, as well as to start, stop, or restart a service.

Do not use the service utility

Although it is still possible to use the service utility to manage services that have init scripts installed in the /etc/rc.d/init.d/ directory, it is advised that you use the systemctl utility.

7.2.1. Checking the Service Status

To determine the status of a particular service, use the systemctl command in the following form:
systemctl status service_name.service
This command provides detailed information on the service's status. However, if you merely need to verify that a service is running, you can use the systemctl command in the following form instead:
systemctl is-active service_name.service
Example 7.3. Checking the status of the httpd service
Example 7.1, “Enabling the httpd service” illustrated how to enable starting the httpd service at boot time. Imagine that the system has been restarted and you need to verify that the service is really running. You can do so by typing the following at a shell prompt:
~]$ systemctl is-active httpd.service
active
You can also display detailed information about the service by running the following command:
~]$ systemctl status httpd.service
httpd.service - LSB: start and stop Apache HTTP Server
          Loaded: loaded (/etc/rc.d/init.d/httpd)
          Active: active (running) since Mon, 23 May 2011 21:38:57 +0200; 27s ago
         Process: 2997 ExecStart=/etc/rc.d/init.d/httpd start (code=exited, status=0/SUCCESS)
        Main PID: 3002 (httpd)
          CGroup: name=systemd:/system/httpd.service
                  ├ 3002 /usr/sbin/httpd
                  ├ 3004 /usr/sbin/httpd
                  ├ 3005 /usr/sbin/httpd
                  ├ 3006 /usr/sbin/httpd
                  ├ 3007 /usr/sbin/httpd
                  ├ 3008 /usr/sbin/httpd
                  ├ 3009 /usr/sbin/httpd
                  ├ 3010 /usr/sbin/httpd
                  └ 3011 /usr/sbin/httpd

To display a list of all active system services, use the following command:
systemctl list-units --type=service
This command provides a tabular output with each line consisting of the following columns:
  • UNIT — A systemd unit name. In this case, a service name.
  • LOAD — Information whether the systemd unit was properly loaded.
  • ACTIVE — A high-level unit activation state.
  • SUB — A low-level unit activation state.
  • JOB — A pending job for the unit.
  • DESCRIPTION — A brief description of the unit.
Example 7.4. Listing all active services
You can list all active services by using the following command:
~]$ systemctl list-units --type=service
UNIT                      LOAD   ACTIVE SUB     JOB DESCRIPTION
abrt-ccpp.service         loaded active exited      LSB: Installs coredump handler which saves segfault data
abrt-oops.service         loaded active running     LSB: Watches system log for oops messages, creates ABRT dump directories for each oops
abrtd.service             loaded active running     ABRT Automated Bug Reporting Tool
accounts-daemon.service   loaded active running     Accounts Service
atd.service               loaded active running     Job spooling tools
[output truncated]
In the example above, the abrtd service is loaded, active, and running, and it does not have any pending jobs.

7.2.2. Running the Service

To run a service, use the systemctl command in the following form:
systemctl start service_name.service
This will start the service in the current session. To configure the service to be started at boot time, refer to Section 7.1.1, “Enabling the Service”.
Example 7.5. Running the httpd service
Example 7.1, “Enabling the httpd service” illustrated how to run the httpd service at boot time. You can start the service immediately by typing the following at a shell prompt as root:
~]# systemctl start httpd.service

7.2.3. Stopping the Service

To stop a service, use the systemctl command in the following form:
systemctl stop service_name.service
This will stop the service in the current session. To disable starting the service at boot time, refer to Section 7.1.1, “Enabling the Service”.
Example 7.6. Stopping the telnet service
Example 7.2, “Disabling the telnet service” illustrated how to disable starting the telnet service at boot time. You can stop the service immediately by running the following command as root:
~]# systemctl stop telnet.service

7.2.4. Restarting the Service

To restart a service, use the systemctl command in the following form:
systemctl restart service_name.service
Example 7.7. Restarting the sshd service
For any changes in the /etc/ssh/sshd_config configuration file to take effect, it is required that you restart the sshd service. You can do so by typing the following at a shell prompt as root:
~]# systemctl restart sshd.service

7.3. Additional Resources

7.3.1. Installed Documentation

  • systemctl(1) — The manual page for the systemctl utility.

7.3.2. Related Books

Fedora 24 Security Guide
A guide to securing Fedora. It contains valuable information on how to set up the firewall, as well as the configuration of SELinux.

Chapter 8. OpenSSH

SSH (Secure Shell) is a protocol which facilitates secure communications between two systems using a client-server architecture and allows users to log into server host systems remotely. Unlike other remote communication protocols, such as FTP, Telnet, or rlogin, 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 into 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 into remote systems decreases the risks for both the client system and the remote host.
Fedora 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.

8.1. The SSH Protocol

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

8.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. Note that if you set the ForwardX11Trusted option to yes or you use SSH with the -Y option, you bypass the X11 SECURITY extension controls, which can result in a security threat.
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.

8.1.3. Protocol Versions

Two varieties of SSH currently exist: version 1 and version 2. The OpenSSH suite under Fedora 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, although version 1 is disabled by default and needs to be enabled in the configuration files.

Avoid using SSH version 1

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

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

8.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 notifies the user that the authenticity of the host cannot be established and prompts the user to accept or reject it. The user is expected to independently verify the new host key before accepting it. 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.

Always verify the integrity of a new SSH server

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.

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

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

8.2. Configuring OpenSSH

In order to perform tasks described in this section, you must have superuser privileges. To obtain them, log in as root by typing:
su -

8.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 8.1, “System-wide configuration files”. User-specific SSH configuration information is stored in ~/.ssh/ within the user's home directory as described in Table 8.2, “User-specific configuration files”.
Table 8.1. System-wide configuration files
File Description
/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 8.2. User-specific configuration files
File Description
~/.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.

8.2.2. Starting an OpenSSH Server

Make sure you have relevant packages installed

To run an OpenSSH server, you must have the openssh-server package installed. See Section 6.2.4, “Installing Packages” for more information on how to install new packages in Fedora 24.
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 the boot time, type as root:
~]# systemctl enable sshd.service
ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service'
See Chapter 7, Services and Daemons for more information on how to configure services in Fedora.
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 8.1, “System-wide configuration files” for a complete list), and restore them whenever you reinstall the system.

8.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.
These services are not installed by default in Fedora. If required, to make sure these services are not running, type the following commands at a shell prompt:
systemctl stop telnet.service
systemctl stop rsh.service
systemctl stop rlogin.service
systemctl stop vsftpd.service
To disable running these services at startup, type:
systemctl disable telnet.service
systemctl disable rsh.service
systemctl disable rlogin.service
systemctl disable vsftpd.service
See Chapter 7, Services and Daemons for more information on how to configure services in Fedora.

8.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.
Fedora 24 uses SSH Protocol 2 and RSA keys by default (see Section 8.1.3, “Protocol Versions” for more information).

Do not generate key pairs as root

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

Backup your ~/.ssh/ directory

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.

8.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 8.2.4.2, “Configuring ssh-agent” for information on how to set up your system to remember the passphrase.

Never share your private key

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

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

8.3. Using OpenSSH Certificate Authentication

8.3.1. Introduction to SSH Certificates

Using public key cryptography for authentication requires copying the public key from every client to every server that the client intends to log into. This system does not scale well and can be an administrative burden. Using a public key from a certificate authority (CA) to authenticate client certificates removes the need to copy keys between multiple systems. While the X.509 Public Key Infrastructure Certificate system provides a solution to this issue, there is a submission and validation process, with associated fees, to go through in order to get a certificate signed. As an alternative, OpenSSH supports the creation of simple certificates and associated CA infrastructure.
OpenSSH certificates contain a public key, identity information, and validity constraints. They are signed with a standard SSH public key using the ssh-keygen utility. The format of the certificate is described in /usr/share/doc/openssh-version/PROTOCOL.certkeys.
The ssh-keygen utility supports two types of certificates: user and host. User certificates authenticate users to servers, whereas host certificates authenticate server hosts to users. For certificates to be used for user or host authentication, sshd must be configured to trust the CA public key.

8.3.2. Support for SSH Certificates

Support for certificate authentication of users and hosts using the new OpenSSH certificate format was introduced in Fedora 13, in the openssh-5.4p1-1.fc13 package. If required, to ensure the latest OpenSSH package is installed, enter the following command as root:
~]# dnf install openssh
Last metadata expiration check performed 0:58:01 ago on Sun Sep  6 16:07:22 2015.
Package openssh-7.1p1-1.fc23.x86_64 is already installed, skipping.

8.3.3. Creating SSH CA Certificate Signing Keys

Two types of certificates are required, host certificates and user certificates. It is considered better to have two separate keys for signing the two certificates, for example ca_user_key and ca_host_key, however it is possible to use just one CA key to sign both certificates. It is also easier to follow the procedures if separate keys are used, so the examples that follow will use separate keys.
The basic format of the command to sign user's public key to create a user certificate is as follows:
ssh-keygen -s ca_user_key -I certificate_ID id_rsa.pub
Where -s indicates the private key used to sign the certificate, -I indicates an identity string, the certificate_ID, which can be any alpha numeric value. It is stored as a zero terminated string in the certificate. The certificate_ID is logged whenever the certificate is used for identification and it is also used when revoking a certificate. Having a long value would make logs hard to read, therefore using the host name for host certificates and the user name for user certificates is a safe choice.
To sign a host's public key to create a host certificate, add the -h option:
ssh-keygen -s ca_host_key -I certificate_ID -h ssh_host_rsa_key.pub
Host keys are generated on the system by default, to list the keys, enter a command as follows:
~]# ls -l /etc/ssh/ssh_host*
-rw-------. 1 root root  668 Jul  9  2014 /etc/ssh/ssh_host_dsa_key
-rw-r--r--. 1 root root  590 Jul  9  2014 /etc/ssh/ssh_host_dsa_key.pub
-rw-------. 1 root root  963 Jul  9  2014 /etc/ssh/ssh_host_key
-rw-r--r--. 1 root root  627 Jul  9  2014 /etc/ssh/ssh_host_key.pub
-rw-------. 1 root root 1671 Jul  9  2014 /etc/ssh/ssh_host_rsa_key
-rw-r--r--. 1 root root  382 Jul  9  2014 /etc/ssh/ssh_host_rsa_key.pub

Important

It is recommended to create and store CA keys in a safe place just as with any other private key. In these examples the root user will be used. In a real production environment using an offline computer with an administrative user account is recommended. For guidance on key lengths see NIST Special Publication 800-131A.
Procedure 8.1. Generating SSH CA Certificate Signing Keys
  1. On the server designated to be the CA, generate two keys for use in signing certificates. These are the keys that all other hosts need to trust. Choose suitable names, for example ca_user_key and ca_host_key. To generate the user certificate signing key, enter the following command as root:
    ~]# ssh-keygen -t rsa -f ~/.ssh/ca_user_key
    Generating public/private rsa key pair.
    Created directory '/root/.ssh'.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /root/.ssh/ca_user_key.
    Your public key has been saved in /root/.ssh/ca_user_key.pub.
    The key fingerprint is:
    11:14:2f:32:fd:5d:f5:e4:7a:5a:d6:b6:a0:62:c9:1f root@host_name.example.com
    The key's randomart image is:
    +--[ RSA 2048]----+
    |       .+.      o|
    |       . o     +.|
    |      o + .   . o|
    |       o + . . ..|
    |        S . ... *|
    |        . . . .*.|
    |         = E  .. |
    |        . o .    |
    |           .     |
    +-----------------+
    Generate a host certificate signing key, ca_host_key, as follows:
    ~]# ssh-keygen -t rsa -f ~/.ssh/ca_host_key
    Generating public/private rsa key pair.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /root/.ssh/ca_host_key.
    Your public key has been saved in /root/.ssh/ca_host_key.pub.
    The key fingerprint is:
    e4:d5:d1:4f:6b:fd:a2:e3:4e:5a:73:52:91:0b:b7:7a root@host_name.example.com
    The key's randomart image is:
    +--[ RSA 2048]----+
    |            ..   |
    |           . ....|
    |        . . o +oo|
    |       o .   o *o|
    |        S     = .|
    |             o. .|
    |            *.E. |
    |           +o=   |
    |          .oo.   |
    +-----------------+
    If required, confirm the permissions are correct:
    ~]# ls -la ~/.ssh
    total 40
    drwxrwxrwx. 2 root root 4096 May 22 13:18 .
    dr-xr-x---. 3 root root 4096 May  8 08:34 ..
    -rw-------. 1 root root 1743 May 22 13:15 ca_host_key
    -rw-r--r--. 1 root root  420 May 22 13:15 ca_host_key.pub
    -rw-------. 1 root root 1743 May 22 13:14 ca_user_key
    -rw-r--r--. 1 root root  420 May 22 13:14 ca_user_key.pub
    -rw-r--r--. 1 root root  854 May  8 05:55 known_hosts
    -r--------. 1 root root 1671 May  6 17:13 ssh_host_rsa
    -rw-r--r--. 1 root root 1370 May  7 14:30 ssh_host_rsa-cert.pub
    -rw-------. 1 root root  420 May  6 17:13 ssh_host_rsa.pub
  2. Create the CA server's own host certificate by signing the server's host public key together with an identification string such as the host name, the CA server's fully qualified domain name (FQDN) but without the trailing ., and a validity period. The command takes the following form:
    ssh-keygen -s ~/.ssh/ca_host_key -I certificate_ID -h -n host_name.example.com -V -start:+end /etc/ssh/ssh_host_rsa.pub
    The -n option restricts this certificate to a specific host within the domain. The -V option is for adding a validity period; this is highly recommend. Where the validity period is intended to be one year, fifty two weeks, consider the need for time to change the certificates and any holiday periods around the time of certificate expiry.
    For example:
    ~]# ssh-keygen -s ~/.ssh/ca_host_key -I host_name -h -n host_name.example.com -V -1w:+54w5d /etc/ssh/ssh_host_rsa.pub
    Enter passphrase:
    Signed host key /root/.ssh/ssh_host_rsa-cert.pub: id "host_name" serial 0 for host_name.example.com valid from 2015-05-15T13:52:29 to 2016-06-08T13:52:29

8.3.4. Distributing and Trusting SSH CA Public Keys

Hosts that are to allow certificate authenticated log in from users must be configured to trust the CA's public key that was used to sign the user certificates, in order to authenticate user's certificates. In this example that is the ca_user_key.pub.
Publish the ca_user_key.pub key and download it to all hosts that are required to allow remote users to log in. Alternately, copy the CA user public key to all the hosts. In a production environment, consider copying the public key to an administrator account first. The secure copy command can be used to copy the public key to remote hosts. The command has the following format:
scp ~/.ssh/ca_user_key.pub root@host_name.example.com:/etc/ssh/
Where host_name is the host name of a server the is required to authenticate user's certificates presented during the login process. Ensure you copy the public key not the private key. For example, as root:
~]# scp ~/.ssh/ca_user_key.pub root@host_name.example.com:/etc/ssh/
The authenticity of host 'host_name.example.com (10.34.74.56)' can't be established.
RSA key fingerprint is fc:23:ad:ae:10:6f:d1:a1:67:ee:b1:d5:37:d4:b0:2f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'host_name.example.com,10.34.74.56' (RSA) to the list of known hosts.
root@host_name.example.com's password:
ca_user_key.pub                                       100%  420     0.4KB/s   00:00
For remote user authentication, CA keys can be marked as trusted per-user in the ~/.ssh/authorized_keys file using the cert-authority directive or for global use by means of the TrustedUserCAKeys directive in the /etc/ssh/sshd_config file. For remote host authentication, CA keys can be marked as trusted globally in the /etc/ssh/known_hosts file or per-user in the ~/.ssh/ssh_known_hosts file.
Procedure 8.2. Trusting the User Signing Key
  • For user certificates which have one or more principles listed, and where the setting is to have global effect, edit the /etc/ssh/sshd_config file as follows:
    TrustedUserCAKeys /etc/ssh/ca_user_key.pub
    Restart sshd to make the changes take effect:
    ~]# service sshd restart
To avoid being presented with the warning about an unknown host, a user's system must trust the CA's public key that was used to sign the host certificates. In this example that is ca_host_key.pub.
Procedure 8.3. Trusting the Host Signing Key
  1. Extract the contents of the public key used to sign the host certificate. For example, on the CA:
    cat ~/.ssh/ca_host_key.pub
    ssh-rsa  AAAAB5Wm.== root@ca-server.example.com
  2. To configure client systems to trust servers' signed host certificates, add the contents of the ca_host_key.pub into the global known_hosts file. This will automatically check a server's host advertised certificate against the CA public key for all users every time a new machine is connected to in the domain *.example.com. Login as root and configure the /etc/ssh/ssh_known_hosts file, as follows:
    ~]# vi /etc/ssh/ssh_known_hosts
    # A CA key, accepted for any host in *.example.com
    @cert-authority *.example.com ssh-rsa AAAAB5Wm.
    Where ssh-rsa AAAAB5Wm. is the contents of ca_host_key.pub. The above configures the system to trust the CA servers host public key. This enables global authentication of the certificates presented by hosts to remote users.

8.3.5. Creating SSH Certificates

A certifcate is a signed public key. The user's and host's public keys must be copied to the CA server for signing by the CA server's private key.

Important

Copying many keys to the CA to be signed can create confusion if they are not uniquely named. If the default name is always used then the latest key to be copied will overwrite the previously copied key, which may be an acceptable method for one administrator. In the example below the default name is used. In a production environment, consider using easily recognizable names. It is recommend to have a designated directory on the CA server owned by an administrative user for the keys to be copied into. Copying these keys to the root user's /etc/ssh/ directory is not recommend. In the examples below an account named admin with a directory named keys/ will be used.
Create an administrator account, in this example admin, and a directory to receive the user's keys. For example:
~]$ mkdir keys
Set the permissions to allow keys to be copied in:
~]$ chmod o+w keys
ls -la keys
total 8
drwxrwxrwx. 2 admin admin 4096 May 22 16:17 .
drwx------. 3 admin admin 4096 May 22 16:17 ..

8.3.5.1. Creating SSH Certificates to Authenticate Hosts

The command to sign a host certificate has the following format:
ssh-keygen -s ca_host_key -I host_name -h ssh_host_rsa_key.pub
The host certificate will named ssh_host_rsa_key-cert.pub.
Procedure 8.4. Generating a Host Certificate
To authenticate a host to a user, a public key must be generated on the host, passed to the CA server, signed by the CA, and then passed back to be stored on the host to present to a user attempting to log into the host.
  1. Host keys are generated automatically on the system. To list them enter the following command:
    ~]# ls -l /etc/ssh/ssh_host*
    -rw-------. 1 root root  668 May  6 14:38 /etc/ssh/ssh_host_dsa_key
    -rw-r--r--. 1 root root  590 May  6 14:38 /etc/ssh/ssh_host_dsa_key.pub
    -rw-------. 1 root root  963 May  6 14:38 /etc/ssh/ssh_host_key
    -rw-r--r--. 1 root root  627 May  6 14:38 /etc/ssh/ssh_host_key.pub
    -rw-------. 1 root root 1679 May  6 14:38 /etc/ssh/ssh_host_rsa_key
    -rw-r--r--. 1 root root  382 May  6 14:38 /etc/ssh/ssh_host_rsa_key.pub
  2. Copy the chosen public key to the server designated as the CA. For example, from the host:
    ~]# scp /etc/ssh/ssh_host_rsa_key.pub admin@ca-server.example.com:~/keys/ssh_host_rsa_key.pub
    The authenticity of host 'ca-server.example.com (10.34.74.58)' can't be established.
    RSA key fingerprint is b0:e5:ea:b8:75:e2:f0:b1:fe:5b:07:39:7f:58:64:d9.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added 'ca-server.example.com,10.34.74.58' (RSA) to the list of known hosts.
    admin@ca-server.example.com's password:
    ssh_host_rsa_key.pub                           100%  382     0.4KB/s   00:00
    Alternately, from the CA:
    ~]$ scp root@host_name.example.com:/etc/ssh/ssh_host_rsa_key.pub ~/keys/ssh_host_rsa_key.pub
  3. On the CA server, sign the host's public key. For example, as root:
    ~]# ssh-keygen -s ~/.ssh/ca_host_key -I host_name -h -n host_name.example.com -V -1d:+54w /home/admin/keys/ssh_host_rsa_key.pub
    Enter passphrase:
    Signed host key /home/admin/keys/ssh_host_rsa_key-cert.pub: id "host_name" serial 0 for host_name.example.com valid from 2015-05-26T12:21:54 to 2016-06-08T12:21:54
    Where host_name is the host name of the system requiring the certificate.
  4. Copy the certificate to the host. For example, from the CA:
    ~]# scp /home/admin/keys/ssh_host_rsa_key-cert.pub root@host_name.example.com:/etc/ssh/
    root@host_name.example.com's password:
    ssh_host_rsa_key-cert.pub                      100% 1384     1.5KB/s   00:00
  5. Configure the host to present the certificate to a user's system when a user initiates the login process. As root, edit the /etc/ssh/sshd_config file as follows:
    HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
  6. Restart sshd to make the changes take effect:
    ~]# service sshd restart
  7. On user's systems. remove keys belonging to hosts from the ~/.ssh/known_hosts file if the user has previously logged into the host configured above. When a user logs into the host they should no longer be presented with the warning about the hosts authenticity.
To test the host certificate, on a client system, ensure the client has set up the global /etc/ssh/known_hosts file, as described in Procedure 8.3, “Trusting the Host Signing Key”, and that the server's public key is not in the ~/.ssh/known_hosts file. Then attempt to log into the server over SSH as a remote user. You should not see a warning about the authenticity of the host. If required, add the -v option to the SSH command to see logging information.

8.3.5.2. Creating SSH Certificates for Authenticating Users

To sign a user's certificate, use a command in the following format:
ssh-keygen -s ca_user_key -I user_name -n user_name -V -start:+end id_rsa.pub
The resulting certificate will be named id_rsa-cert.pub.
The default behavior of OpenSSH is that a user is allowed to log in as a remote user if one of the principals specified in the certificate matches the remote user's name. This can be adjusted in the following ways:
  • Add more user's names to the certificate during the signing process using the -n option:
    -n "name1[,name2,...]"
  • On the user's system, add the public key of the CA in the ~/.ssh/authorized_keys file using the cert-authority directive and list the principals names as follows:
    ~]# vi ~/.ssh/authorized_keys
    # A CA key, accepted for any host in *.example.com
    @cert-authority principals="name1,name2" *.example.com ssh-rsa AAAAB5Wm.
  • On the server, create an AuthorizedPrincipalsFile file, either per user or glabally, and add the principles' names to the file for those users allowed to log in. Then in the /etc/ssh/sshd_config file, specify the file using the AuthorizedPrincipalsFile directive.
Procedure 8.5. Generating a User Certificate
To authenticate a user to a remote host, a public key must be generated by the user, passed to the CA server, signed by the CA, and then passed back to be stored by the user for use when logging in to a host.
  1. On client systems, login as the user who requires the certificate. Check for available keys as follows:
    ~]$ ls -l ~/.ssh/
    If no suitable public key exists, generate one and set the directory permissions if the directory is not the default directory. For example, enter the following command:
    ~]$ ssh-keygen -t rsa
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/user1/.ssh/id_rsa):
    Created directory '/home/user1/.ssh'.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/user1/.ssh/id_rsa.
    Your public key has been saved in /home/user1/.ssh/id_rsa.pub.
    The key fingerprint is:
    b1:f8:26:a7:46:87:c3:60:54:a3:6d:85:0d:60:fe:ce user1@host1.example.com
    The key's randomart image is:
    +--[ RSA 2048]----+
    |    oo++.        |
    |   o.o.o.        |
    |   .o o .        |
    |    oo . o       |
    |   . oo.S        |
    |     o=..        |
    |     .Eo+        |
    |      .=         |
    |     ..          |
    +-----------------+
    By default the directory permissions for a user's keys are drwx------., or octal 0700. If required, confirm the permissions are correct:
    ~]$ ls -la ~/.ssh
    total 16
    drwx------. 2 user1 user1 4096 May  7 12:37 .
    drwx------. 3 user1 user1 4096 May  7 12:37 ..
    -rw-------. 1 user1 user1 1679 May  7 12:37 id_rsa
    -rw-r--r--. 1 user1 user1  421 May  7 12:37 id_rsa.pub
    See Section 8.2.4, “Using Key-based Authentication” for more examples of key generation and for instructions on setting the correct directory permissions.
  2. The chosen public key must be copied to the server designated as the CA, in order to be signed. The secure copy command can be used to do this, the command has the following format:
    scp ~/.ssh/id_protocol.pub admin@ca_server.example.com:~/keys/
    Where protocol is the part of the file name indicating the protocol used to generate the key, for example rsa, admin is an account on the CA server, and /keys/ is a directory setup to receive the keys to be signed.
    Copy the chosen public key to the server designated as the CA. For example:
    ~]$ scp ~/.ssh/id_rsa.pub admin@ca-server.example.com:~/keys/
    admin@ca-server.example.com's password:
    id_rsa.pub                                  100%  421     0.4KB/s   00:00
    If you have configured the client system to trust the host signing key as described in Procedure 8.3, “Trusting the Host Signing Key” then you should not see a warning about the authenticity of the remote host.
  3. On the CA server, sign the user's public key. For example, as root:
    ~]# ssh-keygen -s ~/.ssh/ca_user_key -I user1 -n user1 -V -1d:+54w /home/admin/keys/id_rsa.pub
    Enter passphrase:
    Signed user key /home/admin/keys/id_rsa-cert.pub: id "user1" serial 0 for host_name.example.com valid from 2015-05-21T16:43:17 to 2016-06-03T16:43:17
  4. Copy the resulting certificate to the user's ~/.ssh/ directory on their system. For example:
    ~]# scp /home/admin/keys/id_rsa-cert.pub user1@host_name.example.com:~/.ssh/
    user1@host_name.example.com's password:
    id_rsa-cert.pub                             100%  1498    1.5KB/s   00:00
  5. If using the standard file names and location then no further configuration is required as the SSH daemon will search for user certificates ending in -cert.pub and use them automatically if it finds them. Note that the default location and file names for for SSH version 2 keys are: ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa as explained in the ssh_config(5) manual page. If you use these locations and naming conventions then there is no need for editing the configuration files to enable sshd to present the certificate. They will be used automatically when logging in to a remote system. In this is the case then skip to step 6.
    If required to use a non-default directory or file naming convention, then as root, add the following line to the /etc/ssh/ssh_config or ~/.ssh/config files:
    IdentityFile ~/path/key_file
    Note that this must be the private key name, do not had .pub or -cert.pub. Ensure the file permission are correct. For example:
    ~]$ ls -la ~/.ssh/config
    -rw-rw-r--. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config
    chmod 700 ~/.ssh/config
    ~]$ ls -la ~/.ssh/config
    -rwx------. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config
    This will enable the user of this system to be authenticated by a user certificate when logging into a remote system configured to trust the CA user certificate signing key.
  6. To test the user certificate, attempt to log into a server over SSH from the user's account. You should do this as the user listed as a principle in the certificate, if any are specified. You should not be prompted for a password. If required, add the -v option to the SSH command to see logging information.

8.3.6. Signing an SSH Certificate Using a PKCS#11 Token

It is possible to sign a host key using a CA key stored in a PKCS#11 token by providing the token library using the -D and identifying the CA key by providing its public half as an argument to the -s option:
ssh-keygen -s ca_host_key.pub -D libpkcs11.so -I certificate_ID host_key.pub
In all cases, certificate_ID is a key identifier that is logged by the server when the certificate is used for authentication.
Certificates may be configured to be valid only for a set of users or host names, the principals. By default, generated certificates are valid for all users or hosts. To generate a certificate for a specified set of principals, use a comma separated list with the -n option as follows:
ssh-keygen -s ca_user_key.pub -D libpkcs11.so -I certificate_ID -n user1,user2 id_rsa.pub
and for hosts:
ssh-keygen -s ca_host_key.pub -D libpkcs11.so -I certificate_ID -h -n host.domain ssh_host_rsa_key.pub
Additional limitations on the validity and use of user certificates may be specified through certificate options. A certificate option may disable features of the SSH session, may be valid only when presented from particular source addresses or may force the use of a specific command. For a list of valid certificate options, see the ssh-keygen(1) manual page for the -O option.
Certificates may be defined to be valid for a specific lifetime. The -V option allows specifying a certificates start and end times. For example:
ssh-keygen -s ca_user_key -I certificate_ID id_rsa.pub -V "-1w:+54w5d"
A certificate that is presented at a time outside this range will not be considered valid. By default, certificates are valid indefinitely starting from UNIX Epoch.

8.3.7. Viewing an SSH CA Certificate

To view a certificate, use the -L to list the contents. For example, for a user's certificate:
~]$ ssh-keygen -L -f ~/.ssh/id_rsa-cert.pub
/home/user1/.ssh/id_rsa-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com user certificate
        Public key: RSA-CERT 3c:9d:42:ed:65:b6:0f:18:bf:52:77:c6:02:0e:e5:86
        Signing CA: RSA b1:8e:0b:ce:fe:1b:67:59:f1:74:cd:32:af:5f:c6:e8
        Key ID: "user1"
        Serial: 0
        Valid: from 2015-05-27T00:09:16 to 2016-06-09T00:09:16
        Principals:
                user1
        Critical Options: (none)
        Extensions:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc
To vew a host certificate:
~]# ssh-keygen -L -f /etc/ssh/ssh_host_rsa_key-cert.pub
/etc/ssh/ssh_host_rsa_key-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com host certificate
        Public key: RSA-CERT 1d:71:61:50:05:9b:ec:64:34:27:a5:cc:67:24:03:23
        Signing CA: RSA e4:d5:d1:4f:6b:fd:a2:e3:4e:5a:73:52:91:0b:b7:7a
        Key ID: "host_name"
        Serial: 0
        Valid: from 2015-05-26T17:19:01 to 2016-06-08T17:19:01
        Principals:
                host_name.example.com
        Critical Options: (none)
        Extensions: (none)

8.3.8. Revoking an SSH CA Certificate

If a certificate is stolen, it should be revoked. Although OpenSSH does not provide a mechanism to distribute the revocation list it is still easier to create the revocation list and distribute it by other means then to change the CA keys and all host and user certificates previously created and distributed.
Keys can be revoked by adding them to the revoked_keys file and specifying the file name in the sshd_config file as follows:
RevokedKeys /etc/ssh/revoked_keys
Note that if this file is not readable, then public key authentication will be refused for all users.
A new key revocation list can be generated as follows:
~]$ ssh-keygen -kf  /etc/ssh/revoked_keys -z 1 ~/.ssh/id_rsa.pub
To add lines to the list, use the -u option to update the list:
ssh-keygen -ukf /etc/ssh/revoked_keys -z integer ~/.ssh/id_rsa.pub
where integer is the line number.
To test if a key has been revoked, query the revocation list for the presence of the key. Use a command as follows:
ssh-keygen -Qf /etc/ssh/revoked_keys ~/.ssh/id_rsa.pub
A user can revoke a CA certificate by changing the cert-authority directive to revoke in the known_hosts file.

8.4. OpenSSH Clients

Make sure you have relevant packages installed

To connect to an OpenSSH server from a client machine, you must have the openssh-clients package installed. See Section 6.2.4, “Installing Packages” for more information on how to install new packages in Fedora 24.

8.4.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:

Updating the host key of an SSH server

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 Fedora 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:
Fedora release 20 (Heisenbug)
After you enter the correct password, the user name will be displayed, and you will return to your local shell prompt.

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

8.4.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 8.3, “A selection of available sftp commands”).
Table 8.3. A selection of available sftp commands
Command Description
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.

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

8.5.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:
~]# dnf group install "X Window System"
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.

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

Using reserved port numbers

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.

A connection is only as secure as a client system

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.

8.6. Additional Resources

For more information on how to configure or connect to an OpenSSH server on Fedora, 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.


[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 9. 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 network: a server shares its output (vncserver) and a client (vncviewer) connects to the server.

Note

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

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

9.1.1. Installing VNC Server

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

9.1.2. Configuring VNC Server

Procedure 9.1. Configuring the first VNC connection
  1. A configuration file named /etc/systemd/system/vncserver@.service is required. To create this file, copy the /lib/systemd/system/vncserver@.service file as root:
    ~]# cp /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 9.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=/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.

9.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:
    

9.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 9.1, “Configuring the first VNC connection” 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.

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

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

9.2. VNC Viewer

vncviewer is the program which shows the shared graphical user interfaces and controls the server.
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.

9.2.1. Installing VNC Viewer

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

9.2.2. Connecting to VNC Server

Once the VNC server is configured, you can connect to it from any VNC viewer. In order to do so, issue the vncviewer command in the following format:
vncviewer address:port_number
Where address is an IP or host name.
Example 9.1. One Client Connecting to VNC Server
With the IP address 192.168.0.4 and display number 3 the command looks as follows:
~]$ vncviewer 192.168.0.4:3

9.2.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 port: 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 9.3, “Opening Ports in firewalld”.
Procedure 9.2. 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
    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 9.3. 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.
For more information on opening and closing ports in firewalld, see the Red Hat Enterprise Linux 7 Security Guide.

9.2.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 9.2. 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=/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 8, OpenSSH.

9.3. Additional Resources

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

Installed Documentation

  • vncserver(1) — The VNC server manual pages.
  • vncviewer(1) — The VNC viewer manual pages.
  • vncpasswd(1) — The VNC password manual pages.

Part IV. 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.

Table of Contents

10. Web Servers
10.1. The Apache HTTP Server
10.1.1. Notable Changes
10.1.2. Updating the Configuration
10.1.3. Running the httpd Service
10.1.4. Editing the Configuration Files
10.1.5. Working with Modules
10.1.6. Setting Up Virtual Hosts
10.1.7. Setting Up an SSL Server
10.1.8. Additional Resources
11. Mail Servers
11.1. Email Protocols
11.1.1. Mail Transport Protocols
11.1.2. Mail Access Protocols
11.2. Email Program Classifications
11.2.1. Mail Transport Agent
11.2.2. Mail Delivery Agent
11.2.3. Mail User Agent
11.3. Mail Transport Agents
11.3.1. Postfix
11.3.2. Sendmail
11.3.3. Fetchmail
11.3.4. Mail Transport Agent (MTA) Configuration
11.4. Mail Delivery Agents
11.4.1. Procmail Configuration
11.4.2. Procmail Recipes
11.5. Mail User Agents
11.5.1. Securing Communication
11.6. Additional Resources
11.6.1. Installed Documentation
11.6.2. Useful Websites
11.6.3. Related Books
12. Directory Servers
12.1. OpenLDAP
12.1.1. Introduction to LDAP
12.1.2. Installing the OpenLDAP Suite
12.1.3. Configuring an OpenLDAP Server
12.1.4. SELinux Policy for Applications Using LDAP
12.1.5. Running an OpenLDAP Server
12.1.6. Configuring a System to Authenticate Using OpenLDAP
12.1.7. Additional Resources
12.1.8. Related Books
13. File and Print Servers
13.1. Samba
13.1.1. Introduction to Samba
13.1.2. Samba Daemons and Related Services
13.1.3. Connecting to a Samba Share
13.1.4. Mounting the Share
13.1.5. Configuring a Samba Server
13.1.6. Starting and Stopping Samba
13.1.7. Samba Server Types and the smb.conf File
13.1.8. Samba Security Modes
13.1.9. Samba Account Information Databases
13.1.10. Samba Network Browsing
13.1.11. Samba with CUPS Printing Support
13.1.12. Samba Distribution Programs
13.1.13. Additional Resources
13.2. FTP
13.2.1. The File Transfer Protocol
13.2.2. FTP Servers
13.2.3. Files Installed with vsftpd
13.2.4. Starting and Stopping vsftpd
13.2.5. vsftpd Configuration Options
13.2.6. Additional Resources
13.3. Printer Configuration
13.3.1. Starting the Printers Configuration Tool
13.3.2. Starting Printer Setup
13.3.3. Adding a Local Printer
13.3.4. Adding an AppSocket/HP JetDirect printer
13.3.5. Adding an IPP Printer
13.3.6. Adding an LPD/LPR Host or Printer
13.3.7. Adding a Samba (SMB) printer
13.3.8. Selecting the Printer Model and Finishing
13.3.9. Printing a Test Page
13.3.10. Modifying Existing Printers
13.3.11. Additional Resources
14. Configuring NTP Using the chrony Suite
14.1. Introduction to the chrony Suite
14.1.1. Differences Between ntpd and chronyd
14.1.2. Choosing Between NTP Daemons
14.2. Understanding chrony and Its Configuration
14.2.1. Understanding chronyd
14.2.2. Understanding chronyc
14.2.3. Understanding the chrony Configuration Commands
14.2.4. Security with chronyc
14.3. Using chrony
14.3.1. Installing chrony
14.3.2. Checking the Status of chronyd
14.3.3. Starting chronyd
14.3.4. Stopping chronyd
14.3.5. Checking if chrony is Synchronized
14.3.6. Manually Adjusting the System Clock
14.4. Setting Up chrony for Different Environments
14.4.1. Setting Up chrony for a System Which is Infrequently Connected
14.4.2. Setting Up chrony for a System in an Isolated Network
14.5. Using chronyc
14.5.1. Using chronyc to Control chronyd
14.5.2. Using chronyc for Remote Administration
14.6. Additional Resources
14.6.1. Installed Documentation
14.6.2. Online Documentation
15. Configuring NTP Using ntpd
15.1. Introduction to NTP
15.2. NTP Strata
15.3. Understanding NTP
15.4. Understanding the Drift File
15.5. UTC, Timezones, and DST
15.6. Authentication Options for NTP
15.7. Managing the Time on Virtual Machines
15.8. Understanding Leap Seconds
15.9. Understanding the ntpd Configuration File
15.10. Understanding the ntpd Sysconfig File
15.11. Disabling chrony
15.12. Checking if the NTP Daemon is Installed
15.13. Installing the NTP Daemon (ntpd)
15.14. Checking the Status of NTP
15.15. Configure the Firewall to Allow Incoming NTP Packets
15.15.1. Change the Firewall Settings
15.15.2. Open Ports in the Firewall for NTP Packets
15.16. Configure ntpdate Servers
15.17. Configure NTP
15.17.1. Configure Access Control to an NTP Service
15.17.2. Configure Rate Limiting Access to an NTP Service
15.17.3. Adding a Peer Address
15.17.4. Adding a Server Address
15.17.5. Adding a Broadcast or Multicast Server Address
15.17.6. Adding a Manycast Client Address
15.17.7. Adding a Broadcast Client Address
15.17.8. Adding a Manycast Server Address
15.17.9. Adding a Multicast Client Address
15.17.10. Configuring the Burst Option
15.17.11. Configuring the iburst Option
15.17.12. Configuring Symmetric Authentication Using a Key
15.17.13. Configuring the Poll Interval
15.17.14. Configuring Server Preference
15.17.15. Configuring the Time-to-Live for NTP Packets
15.17.16. Configuring the NTP Version to Use
15.18. Configuring the Hardware Clock Update
15.19. Configuring Clock Sources
15.20. Additional Resources
15.20.1. Installed Documentation
15.20.2. Useful Websites
16. Configuring PTP Using ptp4l
16.1. Introduction to PTP
16.1.1. Understanding PTP
16.1.2. Advantages of PTP
16.2. Using PTP
16.2.1. Checking for Driver and Hardware Support
16.2.2. Installing PTP
16.2.3. Starting ptp4l
16.3. Specifying a Configuration File
16.4. Using the PTP Management Client
16.5. Synchronizing the Clocks
16.6. Verifying Time Synchronization
16.7. Serving PTP Time with NTP
16.8. Serving NTP Time with PTP
16.9. Synchronize to PTP or NTP Time Using timemaster
16.9.1. Starting timemaster as a Service
16.9.2. Understanding the timemaster Configuration File
16.9.3. Configuring timemaster Options
16.10. Improving Accuracy
16.11. Additional Resources
16.11.1. Installed Documentation
16.11.2. Useful Websites

Chapter 10. 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).

10.1. The Apache HTTP Server

The web server available in Fedora is the Apache HTTP server daemon, httpd, an open source web server developed by the Apache Software Foundation. In Fedora 19 the Apache server was updated to Apache HTTP Server 2.4. This section describes the basic configuration of the httpd service, and covers some advanced topics such as adding server modules, setting up virtual hosts, or configuring the secure HTTP server.
There are important differences between the Apache HTTP Server 2.4 and version 2.2, and if you are upgrading from a release prior to Fedora 19, you will need to update the httpd service configuration accordingly. This section reviews some of the newly added features, outlines important changes, and guides you through the update of older configuration files.

10.1.1. Notable Changes

The Apache HTTP Server version 2.4 has the following changes compared to version 2.2:
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. Any configuration files in the conf.modules.d directory are processed before the main body of httpd.conf. Configuration files in the /etc/httpd/conf.d directory 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 Fedora, 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 Fedora 24, 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.
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 Fedora 24:
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.

10.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, edit the /etc/httpd/conf.d/ssl.conf to enable 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.

10.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:
~]# dnf install httpd
For more information on the concept of targets and how to manage system services in Fedora in general, see Chapter 7, Services and Daemons.

10.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
ln -s '/usr/lib/systemd/system/httpd.service' '/etc/systemd/system/multi-user.target.wants/httpd.service'

Using the secure server

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.

10.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
rm '/etc/systemd/system/multi-user.target.wants/httpd.service'

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

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

10.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 10.1, “The httpd service configuration files”.
Table 10.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 10.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.

10.1.4.1. Common httpd.conf Directives

The following directives are commonly used in the /etc/httpd/conf/httpd.conf configuration file:
<Directory>
The <Directory> directive allows you to apply certain directives to a particular directory only. It takes the following form:
<Directory directory>
  directive
  …
</Directory>
The directory can be either a full path to an existing directory in the local file system, or a wildcard expression.
This directive can be used to configure additional cgi-bin directories for server-side scripts located outside the directory that is specified by ScriptAlias. In this case, the ExecCGI and AddHandler directives must be supplied, and the permissions on the target directory must be set correctly (that is, 0755).
Example 10.1. Using the <Directory> directive
<Directory /var/www/html>
  Options Indexes FollowSymLinks
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

<IfDefine>
The IfDefine directive allows you to use certain directives only when a particular parameter is supplied on the command line. It takes the following form:
<IfDefine [!]parameter>
  directive
  …
</IfDefine>
The parameter can be supplied at a shell prompt using the -Dparameter command line option (for example, httpd -DEnableHome). If the optional exclamation mark (that is, !) is present, the enclosed directives are used only when the parameter is not specified.
Example 10.2. Using the <IfDefine> directive
<IfDefine EnableHome>
  UserDir public_html
</IfDefine>

<IfModule>
The <IfModule> directive allows you to use certain directive only when a particular module is loaded. It takes the following form:
<IfModule [!]module>
  directive
  …
</IfModule>
The module can be identified either by its name, or by the file name. If the optional exclamation mark (that is, !) is present, the enclosed directives are used only when the module is not loaded.
Example 10.3. Using the <IfModule> directive
<IfModule mod_disk_cache.c>
  CacheEnable disk /
  CacheRoot /var/cache/mod_proxy
</IfModule>

<Location>
The <Location> directive allows you to apply certain directives to a particular URL only. It takes the following form:
<Location url>
  directive
  …
</Location>
The url can be either a path relative to the directory specified by the DocumentRoot directive (for example, /server-info), or an external URL such as http://example.com/server-info.
Example 10.4. Using the <Location> directive
<Location /server-info>
  SetHandler server-info
  Order deny,allow
  Deny from all
  Allow from .example.com
</Location>

<Proxy>
The <Proxy> directive allows you to apply certain directives to the proxy server only. It takes the following form:
<Proxy pattern>
  directive
  …
</Proxy>
The pattern can be an external URL, or a wildcard expression (for example, http://example.com/*).
Example 10.5. Using the <Proxy> directive
<Proxy *>
  Order deny,allow
  Deny from all
  Allow from .example.com
</Proxy>

<VirtualHost>
The <VirtualHost> directive allows you apply certain directives to particular virtual hosts only. It takes the following form:
<VirtualHost address[:port]…>
  directive
  …
</VirtualHost>
The address can be an IP address, a fully qualified domain name, or a special form as described in Table 10.2, “Available <VirtualHost> options”.
Table 10.2. Available <VirtualHost> options
Option Description
* Represents all IP addresses.
_default_ Represents unmatched IP addresses.

Example 10.6. Using the <VirtualHost> directive
<VirtualHost *:80>
  ServerAdmin webmaster@penguin.example.com
  DocumentRoot /www/docs/penguin.example.com
  ServerName penguin.example.com
  ErrorLog logs/penguin.example.com-error_log
  CustomLog logs/penguin.example.com-access_log common
</VirtualHost>

AccessFileName
The AccessFileName directive allows you to specify the file to be used to customize access control information for each directory. It takes the following form:
AccessFileName filename
The filename is a name of the file to look for in the requested directory. By default, the server looks for .htaccess.
For security reasons, the directive is typically followed by the Files tag to prevent the files beginning with .ht from being accessed by web clients. This includes the .htaccess and .htpasswd files.
Example 10.7. Using the AccessFileName directive
AccessFileName .htaccess

<Files ~ "^\.ht">
  Order allow,deny
  Deny from all
  Satisfy All
</Files>

Action
The Action directive allows you to specify a CGI script to be executed when a certain media type is requested. It takes the following form:
Action content-type path
The content-type has to be a valid MIME type such as text/html, image/png, or application/pdf. The path refers to an existing CGI script, and must be relative to the directory specified by the DocumentRoot directive (for example, /cgi-bin/process-image.cgi).
Example 10.8. Using the Action directive
Action image/png /cgi-bin/process-image.cgi

AddDescription
The AddDescription directive allows you to specify a short description to be displayed in server-generated directory listings for a given file. It takes the following form:
AddDescription "description" filename
The description should be a short text enclosed in double quotes (that is, "). The filename can be a full file name, a file extension, or a wildcard expression.
Example 10.9. Using the AddDescription directive
AddDescription "GZIP compressed tar archive" .tgz

AddEncoding
The AddEncoding directive allows you to specify an encoding type for a particular file extension. It takes the following form:
AddEncoding encoding extension
The encoding has to be a valid MIME encoding such as x-compress, x-gzip, etc. The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .gz).
This directive is typically used to instruct web browsers to decompress certain file types as they are downloaded.
Example 10.10. Using the AddEncoding directive
AddEncoding x-gzip .gz .tgz

AddHandler
The AddHandler directive allows you to map certain file extensions to a selected handler. It takes the following form:
AddHandler handler extension
The handler has to be a name of previously defined handler. The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .cgi).
This directive is typically used to treat files with the .cgi extension as CGI scripts regardless of the directory they are in. Additionally, it is also commonly used to process server-parsed HTML and image-map files.
Example 10.11. Using the AddHandler option
AddHandler cgi-script .cgi

AddIcon
The AddIcon directive allows you to specify an icon to be displayed for a particular file in server-generated directory listings. It takes the following form:
AddIcon path pattern
The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/folder.png). The pattern can be a file name, a file extension, a wildcard expression, or a special form as described in the following table:
Table 10.3. Available AddIcon options
Option Description
^^DIRECTORY^^ Represents a directory.
^^BLANKICON^^ Represents a blank line.

Example 10.12. Using the AddIcon directive
AddIcon /icons/text.png .txt README

AddIconByEncoding
The AddIconByEncoding directive allows you to specify an icon to be displayed for a particular encoding type in server-generated directory listings. It takes the following form:
AddIconByEncoding path encoding
The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/compressed.png). The encoding has to be a valid MIME encoding such as x-compress, x-gzip, etc.
Example 10.13. Using the AddIconByEncoding directive
AddIconByEncoding /icons/compressed.png x-compress x-gzip

AddIconByType
The AddIconByType directive allows you to specify an icon to be displayed for a particular media type in server-generated directory listings. It takes the following form:
AddIconByType path content-type
The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/text.png). The content-type has to be either a valid MIME type (for example, text/html or image/png), or a wildcard expression such as text/*, image/*, etc.
Example 10.14. Using the AddIconByType directive
AddIconByType /icons/video.png video/*

AddLanguage
The AddLanguage directive allows you to associate a file extension with a specific language. It takes the following form:
AddLanguage language extension
The language has to be a valid MIME language such as cs, en, or fr. The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .cs).
This directive is especially useful for web servers that serve content in multiple languages based on the client's language settings.
Example 10.15. Using the AddLanguage directive
AddLanguage cs .cs .cz

AddType
The AddType directive allows you to define or override the media type for a particular file extension. It takes the following form:
AddType content-type extension
The content-type has to be a valid MIME type such as text/html, image/png, etc. The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .cs).
Example 10.16. Using the AddType directive
AddType application/x-gzip .gz .tgz

Alias
The Alias directive allows you to refer to files and directories outside the default directory specified by the DocumentRoot directive. It takes the following form:
Alias url-path real-path
The url-path must be relative to the directory specified by the DocumentRoot directive (for example, /images/). The real-path is a full path to a file or directory in the local file system.
This directive is typically followed by the Directory tag with additional permissions to access the target directory. By default, the /icons/ alias is created so that the icons from /var/www/icons/ are displayed in server-generated directory listings.
Example 10.17. Using the Alias directive
Alias /icons/ /var/www/icons/

<Directory "/var/www/icons">
  Options Indexes MultiViews FollowSymLinks
  AllowOverride None
  Order allow,deny
  Allow from all
<Directory>

Allow
The Allow directive allows you to specify which clients have permission to access a given directory. It takes the following form:
Allow from client
The client can be a domain name, an IP address (both full and partial), a network/netmask pair, or all for all clients.
Example 10.18. Using the Allow directive
Allow from 192.168.1.0/255.255.255.0

AllowOverride
The AllowOverride directive allows you to specify which directives in a .htaccess file can override the default configuration. It takes the following form:
AllowOverride type
The type has to be one of the available grouping options as described in Table 10.4, “Available AllowOverride options”.
Table 10.4. Available AllowOverride options
Option Description
All All directives in .htaccess are allowed to override earlier configuration settings.
None No directive in .htaccess is allowed to override earlier configuration settings.
AuthConfig Allows the use of authorization directives such as AuthName, AuthType, or Require.
FileInfo Allows the use of file type, metadata, and mod_rewrite directives such as DefaultType, RequestHeader, or RewriteEngine, as well as the Action directive.
Indexes Allows the use of directory indexing directives such as AddDescription, AddIcon, or FancyIndexing.
Limit Allows the use of host access directives, that is, Allow, Deny, and Order.
Options[=option,…] Allows the use of the Options directive. Additionally, you can provide a comma-separated list of options to customize which options can be set using this directive.

Example 10.19. Using the AllowOverride directive
AllowOverride FileInfo AuthConfig Limit

BrowserMatch
The BrowserMatch directive allows you to modify the server behavior based on the client's web browser type. It takes the following form:
BrowserMatch pattern variable
The pattern is a regular expression to match the User-Agent HTTP header field. The variable is an environment variable that is set when the header field matches the pattern.
By default, this directive is used to deny connections to specific browsers with known issues, and to disable keepalives and HTTP header flushes for browsers that are known to have problems with these actions.
Example 10.20. Using the BrowserMatch directive
BrowserMatch "Mozilla/2" nokeepalive

CacheDefaultExpire
The CacheDefaultExpire option allows you to set how long to cache a document that does not have any expiration date or the date of its last modification specified. It takes the following form:
CacheDefaultExpire time
The time is specified in seconds. The default option is 3600 (that is, one hour).
Example 10.21. Using the CacheDefaultExpire directive
CacheDefaultExpire 3600

CacheDisable
The CacheDisable directive allows you to disable caching of certain URLs. It takes the following form:
CacheDisable path
The path must be relative to the directory specified by the DocumentRoot directive (for example, /files/).
Example 10.22. Using the CacheDisable directive
CacheDisable /temporary

CacheEnable
The CacheEnable directive allows you to specify a cache type to be used for certain URLs. It takes the following form:
CacheEnable type url
The type has to be a valid cache type as described in Table 10.5, “Available cache types”. The url can be a path relative to the directory specified by the DocumentRoot directive (for example, /images/), a protocol (for example, ftp://), or an external URL such as http://example.com/.
Table 10.5. Available cache types
Type Description
mem The memory-based storage manager.
disk The disk-based storage manager.
fd The file descriptor cache.

Example 10.23. Using the CacheEnable directive
CacheEnable disk /

CacheLastModifiedFactor
The CacheLastModifiedFactor directive allows you to customize how long to cache a document that does not have any expiration date specified, but that provides information about the date of its last modification. It takes the following form:
CacheLastModifiedFactor number
The number is a coefficient to be used to multiply the time that passed since the last modification of the document. The default option is 0.1 (that is, one tenth).
Example 10.24. Using the CacheLastModifiedFactor directive
CacheLastModifiedFactor 0.1

CacheMaxExpire
The CacheMaxExpire directive allows you to specify the maximum amount of time to cache a document. It takes the following form:
CacheMaxExpire time
The time is specified in seconds. The default option is 86400 (that is, one day).
Example 10.25. Using the CacheMaxExpire directive
CacheMaxExpire 86400

CacheNegotiatedDocs
The CacheNegotiatedDocs directive allows you to enable caching of the documents that were negotiated on the basis of content. It takes the following form:
CacheNegotiatedDocs option
The option has to be a valid keyword as described in Table 10.6, “Available CacheNegotiatedDocs options”. Since the content-negotiated documents may change over time or because of the input from the requester, the default option is Off.
Table 10.6. Available CacheNegotiatedDocs options
Option Description
On Enables caching the content-negotiated documents.
Off Disables caching the content-negotiated documents.

Example 10.26. Using the CacheNegotiatedDocs directive
CacheNegotiatedDocs On

CacheRoot
The CacheRoot directive allows you to specify the directory to store cache files in. It takes the following form:
CacheRoot directory
The directory must be a full path to an existing directory in the local file system. The default option is /var/cache/mod_proxy/.
Example 10.27. Using the CacheRoot directive
CacheRoot /var/cache/mod_proxy

CustomLog
The CustomLog directive allows you to specify the log file name and the log file format. It takes the following form:
CustomLog path format
The path refers to a log file, and must be relative to the directory that is specified by the ServerRoot directive (that is, /etc/httpd/ by default). The format has to be either an explicit format string, or a format name that was previously defined using the LogFormat directive.
Example 10.28. Using the CustomLog directive
CustomLog logs/access_log combined

DefaultIcon
The DefaultIcon directive allows you to specify an icon to be displayed for a file in server-generated directory listings when no other icon is associated with it. It takes the following form:
DefaultIcon path
The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/unknown.png).
Example 10.29. Using the DefaultIcon directive
DefaultIcon /icons/unknown.png

DefaultType
The DefaultType directive allows you to specify a media type to be used in case the proper MIME type cannot be determined by the server. It takes the following form:
DefaultType content-type
The content-type has to be a valid MIME type such as text/html, image/png, application/pdf, etc.
Example 10.30. Using the DefaultType directive
DefaultType text/plain

Deny
The Deny directive allows you to specify which clients are denied access to a given directory. It takes the following form:
Deny from client
The client can be a domain name, an IP address (both full and partial), a network/netmask pair, or all for all clients.
Example 10.31. Using the Deny directive
Deny from 192.168.1.1

DirectoryIndex
The DirectoryIndex directive allows you to specify a document to be served to a client when a directory is requested (that is, when the URL ends with the / character). It takes the following form:
DirectoryIndex filename
The filename is a name of the file to look for in the requested directory. By default, the server looks for index.html, and index.html.var.
Example 10.32. Using the DirectoryIndex directive
DirectoryIndex index.html index.html.var

DocumentRoot
The DocumentRoot directive allows you to specify the main directory from which the content is served. It takes the following form:
DocumentRoot directory
The directory must be a full path to an existing directory in the local file system. The default option is /var/www/html/.
Example 10.33. Using the DocumentRoot directive
DocumentRoot /var/www/html

ErrorDocument
The ErrorDocument directive allows you to specify a document or a message to be displayed as a response to a particular error. It takes the following form:
ErrorDocument error-code action
The error-code has to be a valid code such as 403 (Forbidden), 404 (Not Found), or 500 (Internal Server Error). The action can be either a URL (both local and external), or a message string enclosed in double quotes (that is, ").
Example 10.34. Using the ErrorDocument directive
ErrorDocument 403 "Access Denied"
ErrorDocument 404 /404-not_found.html

ErrorLog
The ErrorLog directive allows you to specify a file to which the server errors are logged. It takes the following form:
ErrorLog path
The path refers to a log file, and can be either absolute, or relative to the directory that is specified by the ServerRoot directive (that is, /etc/httpd/ by default). The default option is logs/error_log
Example 10.35. Using the ErrorLog directive
ErrorLog logs/error_log

ExtendedStatus
The ExtendedStatus directive allows you to enable detailed server status information. It takes the following form:
ExtendedStatus option
The option has to be a valid keyword as described in Table 10.7, “Available ExtendedStatus options”. The default option is Off.
Table 10.7. Available ExtendedStatus options
Option Description
On Enables generating the detailed server status.
Off Disables generating the detailed server status.

Example 10.36. Using the ExtendedStatus directive
ExtendedStatus On

Group
The Group directive allows you to specify the group under which the httpd service will run. It takes the following form:
Group group
The group has to be an existing UNIX group. The default option is apache.
Note that Group is no longer supported inside <VirtualHost>, and has been replaced by the SuexecUserGroup directive.
Example 10.37. Using the Group directive
Group apache

HeaderName
The HeaderName directive allows you to specify a file to be prepended to the beginning of the server-generated directory listing. It takes the following form:
HeaderName filename
The filename is a name of the file to look for in the requested directory. By default, the server looks for HEADER.html.
Example 10.38. Using the HeaderName directive
HeaderName HEADER.html

HostnameLookups
The HostnameLookups directive allows you to enable automatic resolving of IP addresses. It takes the following form:
HostnameLookups option
The option has to be a valid keyword as described in Table 10.8, “Available HostnameLookups options”. To conserve resources on the server, the default option is Off.
Table 10.8. Available HostnameLookups options
Option Description
On Enables resolving the IP address for each connection so that the hostname can be logged. However, this also adds a significant processing overhead.
Double Enables performing the double-reverse DNS lookup. In comparison to the above option, this adds even more processing overhead.
Off Disables resolving the IP address for each connection.

Note that when the presence of hostnames is required in server log files, it is often possible to use one of the many log analyzer tools that perform the DNS lookups more efficiently.
Example 10.39. Using the HostnameLookups directive
HostnameLookups Off

Include
The Include directive allows you to include other configuration files. It takes the following form:
Include filename
The filename can be an absolute path, a path relative to the directory specified by the ServerRoot directive, or a wildcard expression. All configuration files from the /etc/httpd/conf.d/ directory are loaded by default.
Example 10.40. Using the Include directive
Include conf.d/*.conf

IndexIgnore
The IndexIgnore directive allows you to specify a list of file names to be omitted from the server-generated directory listings. It takes the following form:
IndexIgnore filename
The filename option can be either a full file name, or a wildcard expression.
Example 10.41. Using the IndexIgnore directive
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

IndexOptions
The IndexOptions directive allows you to customize the behavior of server-generated directory listings. It takes the following form:
IndexOptions option
The option has to be a valid keyword as described in Table 10.9, “Available directory listing options”. The default options are Charset=UTF-8, FancyIndexing, HTMLTable, NameWidth=*, and VersionSort.
Table 10.9. Available directory listing options
Option Description
Charset=encoding Specifies the character set of a generated web page. The encoding has to be a valid character set such as UTF-8 or ISO-8859-2.
Type=content-type Specifies the media type of a generated web page. The content-type has to be a valid MIME type such as text/html or text/plain.
DescriptionWidth=value Specifies the width of the description column. The value can be either a number of characters, or an asterisk (that is, *) to adjust the width automatically.
FancyIndexing Enables advanced features such as different icons for certain files or possibility to re-sort a directory listing by clicking on a column header.
FolderFirst Enables listing directories first, always placing them above files.
HTMLTable Enables the use of HTML tables for directory listings.
IconsAreLinks Enables using the icons as links.
IconHeight=value Specifies an icon height. The value is a number of pixels.
IconWidth=value Specifies an icon width. The value is a number of pixels.
IgnoreCase Enables sorting files and directories in a case-sensitive manner.
IgnoreClient Disables accepting query variables from a client.
NameWidth=value Specifies the width of the file name column. The value can be either a number of characters, or an asterisk (that is, *) to adjust the width automatically.
ScanHTMLTitles Enables parsing the file for a description (that is, the title element) in case it is not provided by the AddDescription directive.
ShowForbidden Enables listing the files with otherwise restricted access.
SuppressColumnSorting Disables re-sorting a directory listing by clicking on a column header.
SuppressDescription Disables reserving a space for file descriptions.
SuppressHTMLPreamble Disables the use of standard HTML preamble when a file specified by the HeaderName directive is present.
SuppressIcon Disables the use of icons in directory listings.
SuppressLastModified Disables displaying the date of the last modification field in directory listings.
SuppressRules Disables the use of horizontal lines in directory listings.
SuppressSize Disables displaying the file size field in directory listings.
TrackModified Enables returning the Last-Modified and ETag values in the HTTP header.
VersionSort Enables sorting files that contain a version number in the expected manner.
XHTML Enables the use of XHTML 1.0 instead of the default HTML 3.2.

Example 10.42. Using the IndexOptions directive
IndexOptions FancyIndexing VersionSort NameWidth=* HTMLTable Charset=UTF-8

KeepAlive
The KeepAlive directive allows you to enable persistent connections. It takes the following form:
KeepAlive option
The option has to be a valid keyword as described in Table 10.10, “Available KeepAlive options”. The default option is Off.
Table 10.10. Available KeepAlive options
Option Description
On Enables the persistent connections. In this case, the server will accept more than one request per connection.
Off Disables the keep-alive connections.

Note that when the persistent connections are enabled, on a busy server, the number of child processes can increase rapidly and eventually reach the maximum limit, slowing down the server significantly. To reduce the risk, it is recommended that you set KeepAliveTimeout to a low number, and monitor the /var/log/httpd/logs/error_log log file carefully.
Example 10.43. Using the KeepAlive directive
KeepAlive Off

KeepAliveTimeout
The KeepAliveTimeout directive allows you to specify the amount of time to wait for another request before closing the connection. It takes the following form:
KeepAliveTimeout time
The time is specified in seconds. The default option is 15.
Example 10.44. Using the KeepAliveTimeout directive
KeepAliveTimeout 15

LanguagePriority
The LanguagePriority directive allows you to customize the precedence of languages. It takes the following form:
LanguagePriority language
The language has to be a valid MIME language such as cs, en, or fr.
This directive is especially useful for web servers that serve content in multiple languages based on the client's language settings.
Example 10.45. Using the LanguagePriority directive
LanguagePriority sk cs en

Listen
The Listen directive allows you to specify IP addresses or ports to listen to. It takes the following form:
Listen [ip-address:]port [protocol]
The ip-address is optional and unless supplied, the server will accept incoming requests on a given port from all IP addresses. Since the protocol is determined automatically from the port number, it can be usually omitted. The default option is to listen to port 80.
Note that if the server is configured to listen to a port under 1024, only superuser will be able to start the httpd service.
Example 10.46. Using the Listen directive
Listen 80

LoadModule
The LoadModule directive allows you to load a Dynamic Shared Object (DSO) module. It takes the following form:
LoadModule name path
The name has to be a valid identifier of the required module. The path refers to an existing module file, and must be relative to the directory in which the libraries are placed (that is, /usr/lib/httpd/ on 32-bit and /usr/lib64/httpd/ on 64-bit systems by default).
See Section 10.1.5, “Working with Modules” for more information on the Apache HTTP Server's DSO support.
Example 10.47. Using the LoadModule directive
LoadModule php5_module modules/libphp5.so

LogFormat
The LogFormat directive allows you to specify a log file format. It takes the following form:
LogFormat format name
The format is a string consisting of options as described in Table 10.11, “Common LogFormat options”. The name can be used instead of the format string in the CustomLog directive.
Table 10.11. Common LogFormat options
Option Description
%b Represents the size of the response in bytes.
%h Represents the IP address or hostname of a remote client.
%l Represents the remote log name if supplied. If not, a hyphen (that is, -) is used instead.
%r Represents the first line of the request string as it came from the browser or client.
%s Represents the status code.
%t Represents the date and time of the request.
%u If the authentication is required, it represents the remote user. If not, a hyphen (that is, -) is used instead.
%{field} Represents the content of the HTTP header field. The common options include %{Referer} (the URL of the web page that referred the client to the server) and %{User-Agent} (the type of the web browser making the request).

Example 10.48. Using the LogFormat directive
LogFormat "%h %l %u %t \"%r\" %>s %b" common

LogLevel
The LogLevel directive allows you to customize the verbosity level of the error log. It takes the following form:
LogLevel option
The option has to be a valid keyword as described in Table 10.12, “Available LogLevel options”. The default option is warn.
Table 10.12. Available LogLevel options
Option Description
emerg Only the emergency situations when the server cannot perform its work are logged.
alert All situations when an immediate action is required are logged.
crit All critical conditions are logged.
error All error messages are logged.
warn All warning messages are logged.
notice Even normal, but still significant situations are logged.
info Various informational messages are logged.
debug Various debugging messages are logged.

Example 10.49. Using the LogLevel directive
LogLevel warn

MaxKeepAliveRequests
The MaxKeepAliveRequests directive allows you to specify the maximum number of requests for a persistent connection. It takes the following form:
MaxKeepAliveRequests number
A high number can improve the performance of the server. Note that using 0 allows unlimited number of requests. The default option is 100.
Example 10.50. Using the MaxKeepAliveRequests option
MaxKeepAliveRequests 100

NameVirtualHost
The NameVirtualHost directive allows you to specify the IP address and port number for a name-based virtual host. It takes the following form:
NameVirtualHost ip-address[:port]
The ip-address can be either a full IP address, or an asterisk (that is, *) representing all interfaces. Note that IPv6 addresses have to be enclosed in square brackets (that is, [ and ]). The port is optional.
Name-based virtual hosting allows one Apache HTTP Server to serve different domains without using multiple IP addresses.

Using secure HTTP connections

Name-based virtual hosts only work with non-secure HTTP connections. If using virtual hosts with a secure server, use IP address-based virtual hosts instead.
Example 10.51. Using the NameVirtualHost directive
NameVirtualHost *:80

Options
The Options directive allows you to specify which server features are available in a particular directory. It takes the following form:
Options option
The option has to be a valid keyword as described in Table 10.13, “Available server features”.
Table 10.13. Available server features
Option Description
ExecCGI Enables the execution of CGI scripts.
FollowSymLinks Enables following symbolic links in the directory.
Includes Enables server-side includes.
IncludesNOEXEC Enables server-side includes, but does not allow the execution of commands.
Indexes Enables server-generated directory listings.
MultiViews Enables content-negotiated MultiViews.
SymLinksIfOwnerMatch Enables following symbolic links in the directory when both the link and the target file have the same owner.
All Enables all of the features above with the exception of MultiViews.
None Disables all of the features above.

Example 10.52. Using the Options directive
Options Indexes FollowSymLinks

Order
The Order directive allows you to specify the order in which the Allow and Deny directives are evaluated. It takes the following form:
Order option
The option has to be a valid keyword as described in Table 10.14, “Available Order options”. The default option is allow,deny.
Table 10.14. Available Order options
Option Description
allow,deny Allow directives are evaluated first.
deny,allow Deny directives are evaluated first.

Example 10.53. Using the Order directive
Order allow,deny

PidFile
The PidFile directive allows you to specify a file to which the process ID (PID) of the server is stored. It takes the following form:
PidFile path
The path refers to a pid file, and can be either absolute, or relative to the directory that is specified by the ServerRoot directive (that is, /etc/httpd/ by default). The default option is run/httpd.pid.
Example 10.54. Using the PidFile directive
PidFile run/httpd.pid

ProxyRequests
The ProxyRequests directive allows you to enable forward proxy requests. It takes the following form:
ProxyRequests option
The option has to be a valid keyword as described in Table 10.15, “Available ProxyRequests options”. The default option is Off.
Table 10.15. Available ProxyRequests options
Option Description
On Enables forward proxy requests.
Off Disables forward proxy requests.

Example 10.55. Using the ProxyRequests directive
ProxyRequests On

ReadmeName
The ReadmeName directive allows you to specify a file to be appended to the end of the server-generated directory listing. It takes the following form:
ReadmeName filename
The filename is a name of the file to look for in the requested directory. By default, the server looks for README.html.
Example 10.56. Using the ReadmeName directive
ReadmeName README.html

Redirect
The Redirect directive allows you to redirect a client to another URL. It takes the following form:
Redirect [status] path url
The status is optional, and if provided, it has to be a valid keyword as described in Table 10.16, “Available status options”. The path refers to the old location, and must be relative to the directory specified by the DocumentRoot directive (for example, /docs). The url refers to the current location of the content (for example, http://docs.example.com).
Table 10.16. Available status options
Status Description
permanent Indicates that the requested resource has been moved permanently. The 301 (Moved Permanently) status code is returned to a client.
temp Indicates that the requested resource has been moved only temporarily. The 302 (Found) status code is returned to a client.
seeother Indicates that the requested resource has been replaced. The 303 (See Other) status code is returned to a client.
gone Indicates that the requested resource has been removed permanently. The 410 (Gone) status is returned to a client.

Note that for more advanced redirection techniques, you can use the mod_rewrite module that is part of the Apache HTTP Server installation.
Example 10.57. Using the Redirect directive
Redirect permanent /docs http://docs.example.com

ScriptAlias
The ScriptAlias directive allows you to specify the location of CGI scripts. It takes the following form:
ScriptAlias url-path real-path
The url-path must be relative to the directory specified by the DocumentRoot directive (for example, /cgi-bin/). The real-path is a full path to a file or directory in the local file system.
This directive is typically followed by the Directory tag with additional permissions to access the target directory. By default, the /cgi-bin/ alias is created so that the scripts located in the /var/www/cgi-bin/ are accessible.
The ScriptAlias directive is used for security reasons to prevent CGI scripts from being viewed as ordinary text documents.
Example 10.58. Using the ScriptAlias directive
ScriptAlias /cgi-bin/ /var/www/cgi-bin/

<Directory "/var/www/cgi-bin">
  AllowOverride None
  Options None
  Order allow,deny
  Allow from all
</Directory>

ServerAdmin
The ServerAdmin directive allows you to specify the email address of the server administrator to be displayed in server-generated web pages. It takes the following form:
ServerAdmin email
The default option is root@localhost.
This directive is commonly set to webmaster@hostname, where hostname is the address of the server. Once set, alias webmaster to the person responsible for the web server in /etc/aliases, and as superuser, run the newaliases command.
Example 10.59. Using the ServerAdmin directive
ServerAdmin webmaster@penguin.example.com

ServerName
The ServerName directive allows you to specify the hostname and the port number of a web server. It takes the following form:
ServerName hostname[:port]
The hostname has to be a fully qualified domain name (FQDN) of the server. The port is optional, but when supplied, it has to match the number specified by the Listen directive.
When using this directive, make sure that the IP address and server name pair are included in the /etc/hosts file.
Example 10.60. Using the ServerName directive
ServerName penguin.example.com:80

ServerRoot
The ServerRoot directive allows you to specify the directory in which the server operates. It takes the following form:
ServerRoot directory
The directory must be a full path to an existing directory in the local file system. The default option is /etc/httpd/.
Example 10.61. Using the ServerRoot directive
ServerRoot /etc/httpd

ServerSignature
The ServerSignature directive allows you to enable displaying information about the server on server-generated documents. It takes the following form:
ServerSignature option
The option has to be a valid keyword as described in Table 10.17, “Available ServerSignature options”. The default option is On.
Table 10.17. Available ServerSignature options
Option Description
On Enables appending the server name and version to server-generated pages.
Off Disables appending the server name and version to server-generated pages.
EMail Enables appending the server name, version, and the email address of the system administrator as specified by the ServerAdmin directive to server-generated pages.

Example 10.62. Using the ServerSignature directive
ServerSignature On

ServerTokens
The ServerTokens directive allows you to customize what information are included in the Server response header. It takes the following form:
ServerTokens option
The option has to be a valid keyword as described in Table 10.18, “Available ServerTokens options”. The default option is OS.
Table 10.18. Available ServerTokens options
Option Description
Prod Includes the product name only (that is, Apache).
Major Includes the product name and the major version of the server (for example, 2).
Minor Includes the product name and the minor version of the server (for example, 2.2).
Min Includes the product name and the minimal version of the server (for example, 2.2.15).
OS Includes the product name, the minimal version of the server, and the type of the operating system it is running on (for example, Red Hat).
Full Includes all the information above along with the list of loaded modules.

Note that for security reasons, it is recommended to reveal as little information about the server as possible.
Example 10.63. Using the ServerTokens directive
ServerTokens Prod

SuexecUserGroup
The SuexecUserGroup directive allows you to specify the user and group under which the CGI scripts will be run. It takes the following form:
SuexecUserGroup user group
The user has to be an existing user, and the group must be a valid UNIX group.
For security reasons, the CGI scripts should not be run with root privileges. Note that in <VirtualHost>, SuexecUserGroup replaces the User and Group directives.
Example 10.64. Using the SuexecUserGroup directive
SuexecUserGroup apache apache

Timeout
The Timeout directive allows you to specify the amount of time to wait for an event before closing a connection. It takes the following form:
Timeout time
The time is specified in seconds. The default option is 60.
Example 10.65. Using the Timeout directive
Timeout 60

TypesConfig
The TypesConfig allows you to specify the location of the MIME types configuration file. It takes the following form:
TypesConfig path
The path refers to an existing MIME types configuration file, and can be either absolute, or relative to the directory that is specified by the ServerRoot directive (that is, /etc/httpd/ by default). The default option is /etc/mime.types.
Note that instead of editing /etc/mime.types, the recommended way to add MIME type mapping to the Apache HTTP Server is to use the AddType directive.
Example 10.66. Using the TypesConfig directive
TypesConfig /etc/mime.types

UseCanonicalName
The UseCanonicalName allows you to specify the way the server refers to itself. It takes the following form:
UseCanonicalName option
The option has to be a valid keyword as described in Table 10.19, “Available UseCanonicalName options”. The default option is Off.
Table 10.19. Available UseCanonicalName options
Option Description
On Enables the use of the name that is specified by the ServerName directive.
Off Disables the use of the name that is specified by the ServerName directive. The hostname and port number provided by the requesting client are used instead.
DNS Disables the use of the name that is specified by the ServerName directive. The hostname determined by a reverse DNS lookup is used instead.

Example 10.67. Using the UseCanonicalName directive
UseCanonicalName Off

User
The User directive allows you to specify the user under which the httpd service will run. It takes the following form:
User user
The user has to be an existing UNIX user. The default option is apache.
For security reasons, the httpd service should not be run with root privileges. Note that User is no longer supported inside <VirtualHost>, and has been replaced by the SuexecUserGroup directive.
Example 10.68. Using the User directive
User apache

UserDir
The UserDir directive allows you to enable serving content from users' home directories. It takes the following form:
UserDir option
The option can be either a name of the directory to look for in user's home directory (typically public_html), or a valid keyword as described in Table 10.20, “Available UserDir options”. The default option is disabled.
Table 10.20. Available UserDir options
Option Description
enabled user Enables serving content from home directories of given users.
disabled [user] Disables serving content from home directories, either for all users, or, if a space separated list of users is supplied, for given users only.

Set the correct permissions

In order for the web server to access the content, the permissions on relevant directories and files must be set correctly. Make sure that all users are able to access the home directories, and that they can access and read the content of the directory specified by the UserDir directive. For example, to allow access to public_html/ in the home directory of user joe, type the following at a shell prompt as root:
~]# chmod a+x /home/joe/
~]# chmod a+rx /home/joe/public_html/
All files in this directory must be set accordingly.
Example 10.69. Using the UserDir directive
UserDir public_html

10.1.4.2. Common ssl.conf Directives

The Secure Sockets Layer (SSL) directives allow you to customize the behavior of the Apache HTTP Secure Server, and in most cases, they are configured appropriately during the installation. Be careful when changing these settings, as incorrect configuration can lead to security vulnerabilities.
The following directive is commonly used in /etc/httpd/conf.d/ssl.conf:
SetEnvIf
The SetEnvIf directive allows you to set environment variables based on the headers of incoming connections. It takes the following form:
SetEnvIf option pattern [!]variable[=value]…
The option can be either a HTTP header field, a previously defined environment variable name, or a valid keyword as described in Table 10.21, “Available SetEnvIf options”. The pattern is a regular expression. The variable is an environment variable that is set when the option matches the pattern. If the optional exclamation mark (that is, !) is present, the variable is removed instead of being set.
Table 10.21. Available SetEnvIf options
Option Description
Remote_Host Refers to the client's hostname.
Remote_Addr Refers to the client's IP address.
Server_Addr Refers to the server's IP address.
Request_Method Refers to the request method (for example, GET).
Request_Protocol Refers to the protocol name and version (for example, HTTP/1.1).
Request_URI Refers to the requested resource.

The SetEnvIf directive is used to disable HTTP keepalives, and to allow SSL to close the connection without a closing notification from the client browser. This is necessary for certain web browsers that do not reliably shut down the SSL connection.
Example 10.70. Using the SetEnvIf directive
SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

Note that for the /etc/httpd/conf.d/ssl.conf file to be present, the mod_ssl needs to be installed. See Section 10.1.7, “Setting Up an SSL Server” for more information on how to install and configure an SSL server.

10.1.4.3. Common Multi-Processing Module Directives

The Multi-Processing Module (MPM) directives allow you to customize the behavior of a particular MPM specific server-pool. Since its characteristics differ depending on which MPM is used, the directives are embedded in IfModule. By default, the server-pool is defined for both the prefork and worker MPMs.
The following MPM directives are commonly used in /etc/httpd/conf/httpd.conf:
MaxClients
The MaxClients directive allows you to specify the maximum number of simultaneously connected clients to process at one time. It takes the following form:
MaxClients number
A high number can improve the performance of the server, although it is not recommended to exceed 256 when using the prefork MPM.
Example 10.71. Using the MaxClients directive
MaxClients 256

MaxRequestsPerChild
The MaxRequestsPerChild directive allows you to specify the maximum number of request a child process can serve before it dies. It takes the following form:
MaxRequestsPerChild number
Setting the number to 0 allows unlimited number of requests.
The MaxRequestsPerChild directive is used to prevent long-lived processes from causing memory leaks.
Example 10.72. Using the MaxRequestsPerChild directive
MaxRequestsPerChild 4000

MaxSpareServers
The MaxSpareServers directive allows you to specify the maximum number of spare child processes. It takes the following form:
MaxSpareServers number
This directive is used by the prefork MPM only.
Example 10.73. Using the MaxSpareServers directive
MaxSpareServers 20

MaxSpareThreads
The MaxSpareThreads directive allows you to specify the maximum number of spare server threads. It takes the following form:
MaxSpareThreads number
The number must be greater than or equal to the sum of MinSpareThreads and ThreadsPerChild. This directive is used by the worker MPM only.
Example 10.74. Using the MaxSpareThreads directive
MaxSpareThreads 75

MinSpareServers
The MinSpareServers directive allows you to specify the minimum number of spare child processes. It takes the following form:
MinSpareServers number
Note that a high number can create a heavy processing load on the server. This directive is used by the prefork MPM only.
Example 10.75. Using the MinSpareServers directive
MinSpareServers 5

MinSpareThreads
The MinSpareThreads directive allows you to specify the minimum number of spare server threads. It takes the following form:
MinSpareThreads number
This directive is used by the worker MPM only.
Example 10.76. Using the MinSpareThreads directive
MinSpareThreads 75

StartServers
The StartServers directive allows you to specify the number of child processes to create when the service is started. It takes the following form:
StartServers number
Since the child processes are dynamically created and terminated according to the current traffic load, it is usually not necessary to change this value.
Example 10.77. Using the StartServers directive
StartServers 8

ThreadsPerChild
The ThreadsPerChild directive allows you to specify the number of threads a child process can create. It takes the following form:
ThreadsPerChild number
This directive is used by the worker MPM only.
Example 10.78. Using the ThreadsPerChild directive
ThreadsPerChild 25

10.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. By default, these modules are located in /usr/lib/httpd/modules/ on 32-bit and in /usr/lib64/httpd/modules/ on 64-bit systems.

10.1.5.1. Loading a Module

To load a particular DSO module, use the LoadModule directive as described in Section 10.1.4.1, “Common httpd.conf Directives”. Note that modules provided by a separate package often have their own configuration file in the /etc/httpd/conf.d/ directory.
Example 10.79. 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 10.1.3.3, “Restarting the Service” for more information on how to restart the httpd service.

10.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:
~]# dnf 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.

10.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 10.80, “Example virtual host configuration”.
Example 10.80. 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.

Changing the port number

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 10.1.3.3, “Restarting the Service” for more information on how to restart the httpd service.

10.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.
Unlike a regular HTTP connection that can be read and possibly modified by anybody who is able to intercept it, the use of mod_ssl 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.

10.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 10.22, “Information about CA lists used by common web browsers”.
Table 10.22. 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.

10.1.7.2. Enabling the mod_ssl Module

If you intend to set up an SSL server, make sure you have the mod_ssl (the mod_ssl module) and openssl (the OpenSSL toolkit) packages installed. To do so, enter the following command as root:
~]# dnf 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 10.1.3.3, “Restarting the Service”.

Important

Due to the SSL3.0 protocol vulnerability CVE-2014-3566, described in SSL 3.0 Protocol Vulnerability and POODLE Attack, it is recommended to disable SSL and use only TLSv1.1 or TLSv1.2. Backwards compatibility can be achieved using TLSv1.0. Many products 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.

10.1.7.3. 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 10.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.
  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:
    ~]# service httpd restart
    Note that any sessions will be interrupted.

10.1.7.4. 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 10.1.7.5, “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 10.1.3.3, “Restarting the Service”.
Example 10.81. 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

10.1.7.5. 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:
~]# dnf 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.

Replacing an existing certificate

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, use the following command instead of genkey:
~]# openssl req -x509 -new -set_serial number -key hostname.key -out hostname.crt

Remove a previously created key

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
    Running the genkey utility
    Figure 10.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
    Selecting the key size
    Figure 10.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
    Generating a certificate request
    Figure 10.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
    Encrypting the private key
    Figure 10.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
    Entering a passphrase
    Figure 10.5. Entering a passphrase

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

    Do not forget the passphrase

    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
    Specifying certificate information
    Figure 10.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
    Instructions on how to send a certificate request
    Figure 10.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 10.1.3.3, “Restarting the Service”, so that the updated configuration is loaded.

10.1.8. 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:
    ~]# dnf 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.
  • ulink url="http://www.modssl.org/" /> — The official website for the mod_ssl module.
  • http://www.openssl.org/ — The OpenSSL home page containing further documentation, frequently asked questions, links to the mailing lists, and other useful resources.

Chapter 11. Mail Servers

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

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

11.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).

11.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 Fedora, 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.
Fedora provides the Postfix and Sendmail SMTP programs.

11.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).

11.1.2.1. POP

The default POP server under Fedora is Dovecot and is provided by the dovecot package.

Installing the dovecot package

In order to use Dovecot, first ensure the dovecot package is installed on your system by running, as root:
~]# dnf install dovecot
For more information on installing packages with DNF, see Section 6.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 11.5.1, “Securing Communication”.

11.1.2.2. IMAP

The default IMAP server under Fedora is Dovecot and is provided by the dovecot package. See Section 11.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 11.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.

11.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
    ln -s '/usr/lib/systemd/system/dovecot' '/etc/systemd/system/multi-user.target.wants/dovecot'

    The dovecot service starts the POP3 server

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

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

11.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 Fedora offers two MTAs, Postfix and Sendmail, email client programs are often not required to act as an MTA. Fedora also includes a special purpose MTA called Fetchmail.
For more information on Postfix, Sendmail, and Fetchmail, see Section 11.3, “Mail Transport Agents”.

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

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

11.3. Mail Transport Agents

Fedora 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 Fedora 24, see Chapter 7, Services and Daemons.

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

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

Configuring Postfix as a server for other clients

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 11.3.1.2, “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

11.3.1.2. 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/.

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

The /etc/postfix/ldap-aliases.cf file

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 Section 12.1, “OpenLDAP”.

11.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 11.3.1, “Postfix” for more information.

11.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 11.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).

11.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:
~]# dnf install sendmail
In order to configure Sendmail, ensure the sendmail-cf package is installed on your system by running, as root:
~]# dnf install sendmail-cf
For more information on installing packages with DNF, see Section 6.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 11.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 11.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.

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

Backup the sendmail.cf file before changing its content

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

Configuring Sendmail as a server for other clients

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

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

11.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 11.4.2.6, “Spam Filters” for more information about using SpamAssassin.

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

Advanced configuration

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 11.3.2.3, “Common Sendmail Configuration Changes” for instructions.
For more information on LDAP, see Section 12.1, “OpenLDAP”.

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

Installing the fetchmail package

In order to use Fetchmail, first ensure the fetchmail package is installed on your system by running, as root:
~]# dnf install fetchmail
For more information on installing packages with DNF, see Section 6.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.

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

Omitting the password from the configuration

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.

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

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

11.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.
  • user "username" — Replace username with the username used by Fetchmail to retrieve messages. This option must precede all other user options.

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

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

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

11.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, Thunderbird, and 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.
Fedora 24 provides two MTAs: Postfix and Sendmail. If both are installed, Postfix is the default MTA. Note that Sendmail is considered deprecated in MAJOROS;.

11.4. Mail Delivery Agents

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

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

11.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 11.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 11.4.2.4, “Special Conditions and Actions” for more information.

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

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

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

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

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

Sending messages to /dev/null

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 11.6, “Additional Resources” for more detailed and powerful recipes.

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

Installing the spamassassin package

In order to use SpamAssassin, first ensure the spamassassin package is installed on your system by running, as root:
~]# dnf install spamassassin
For more information on installing packages with DNF, see Section 6.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.service
To start the SpamAssassin daemon when the system is booted, run:
systemctl enable spamassassin.service
See Chapter 7, Services and Daemons for more information on how to configure services in Fedora.
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

11.5. Mail User Agents

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

11.5.1. Securing Communication

Popular MUAs included with Fedora, 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.

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

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

Avoid using self-signed certificates

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

Installing the stunnel package

In order to use stunnel, first ensure the stunnel package is installed on your system by running, as root:
~]# dnf install stunnel
For more information on installing packages with DNF, see Section 6.2.4, “Installing Packages”.
To create a self-signed SSL certificate, change to the /etc/pki/tls/certs/ directory, and type the following command:
certs]# make stunnel.pem
Answer all of the questions to complete the process.
Once the certificate is generated, create an stunnel configuration file, for example /etc/stunnel/mail.conf, with the following content:
cert = /etc/pki/tls/certs/stunnel.pem

[pop3s]
accept  = 995
connect = 110

[imaps]
accept  = 993
connect = 143
Once you start stunnel with the created configuration file using the stunnel /etc/stunnel/mail.conf command, it will be possible to use an IMAP or a POP email client and connect to the email server using SSL encryption.
For more information on stunnel, see the stunnel(8) man page or the documents in the /usr/share/doc/stunnel/ directory.

11.6. Additional Resources

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

11.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/ — Contains a large amount of information on how to configure Postfix.
  • /usr/share/doc/fetchmail/ — Contains a full list of Fetchmail features in the FEATURES file and an introductory FAQ document.
  • /usr/share/doc/procmail/ — 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.
    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/ — Contains a large amount of information pertaining to SpamAssassin.

11.6.2. Useful Websites

Chapter 12. Directory Servers

12.1. OpenLDAP

LDAP (Lightweight Directory Access Protocol) is a set of open protocols used to access centrally stored information over a network. It is based on the X.500 standard for directory sharing, but is less complex and resource-intensive. For this reason, LDAP is sometimes referred to as X.500 Lite.
Like X.500, LDAP organizes information in a hierarchical manner using directories. These directories can store a variety of information such as names, addresses, or phone numbers, and can even be used in a manner similar to the Network Information Service (NIS), enabling anyone to access their account from any machine on the LDAP enabled network.
LDAP is commonly used for centrally managed users and groups, user authentication, or system configuration. It can also serve as a virtual phone directory, allowing users to easily access contact information for other users. Additionally, it can refer a user to other LDAP servers throughout the world, and thus provide an ad-hoc global repository of information. However, it is most frequently used within individual organizations such as universities, government departments, and private companies.
This section covers the installation and configuration of OpenLDAP 2.4, an open source implementation of the LDAPv2 and LDAPv3 protocols.

12.1.1. Introduction to LDAP

Using a client-server architecture, LDAP provides a reliable means to create a central information directory accessible from the network. When a client attempts to modify information within this directory, the server verifies the user has permission to make the change, and then adds or updates the entry as requested. To ensure the communication is secure, the Transport Layer Security (TLS) cryptographic protocol can be used to prevent an attacker from intercepting the transmission.

Using Mozilla NSS

The OpenLDAP suite in Fedora 24 no longer uses OpenSSL. Instead, it uses the Mozilla implementation of Network Security Services (NSS). OpenLDAP continues to work with existing certificates, keys, and other TLS configuration. For more information on how to configure it to use Mozilla certificate and key database, see How do I use TLS/SSL with Mozilla NSS.
The LDAP server supports several database systems, which gives administrators the flexibility to choose the best suited solution for the type of information they are planning to serve. Because of a well-defined client Application Programming Interface (API), the number of applications able to communicate with an LDAP server is numerous, and increasing in both quantity and quality.

12.1.1.1. LDAP Terminology

The following is a list of LDAP-specific terms that are used within this chapter:
entry
A single unit within an LDAP directory. Each entry is identified by its unique Distinguished Name (DN).
attribute
Information directly associated with an entry. For example, if an organization is represented as an LDAP entry, attributes associated with this organization might include an address, a fax number, etc. Similarly, people can be represented as entries with common attributes such as personal telephone number or email address.
An attribute can either have a single value, or an unordered space-separated list of values. While certain attributes are optional, others are required. Required attributes are specified using the objectClass definition, and can be found in schema files located in the /etc/openldap/slapd.d/cn=config/cn=schema/ directory.
The assertion of an attribute and its corresponding value is also referred to as a Relative Distinguished Name (RDN). Unlike distinguished names that are unique globally, a relative distinguished name is only unique per entry.
LDIF
The LDAP Data Interchange Format (LDIF) is a plain text representation of an LDAP entry. It takes the following form:
[id] dn: distinguished_name
attribute_type: attribute_valueattribute_type: attribute_value…
…
The optional id is a number determined by the application that is used to edit the entry. Each entry can contain as many attribute_type and attribute_value pairs as needed, as long as they are all defined in a corresponding schema file. A blank line indicates the end of an entry.

12.1.1.2. OpenLDAP Features

OpenLDAP suite provides a number of important features:
  • LDAPv3 Support — Many of the changes in the protocol since LDAP version 2 are designed to make LDAP more secure. Among other improvements, this includes the support for Simple Authentication and Security Layer (SASL), Transport Layer Security (TLS), and Secure Sockets Layer (SSL) protocols.
  • LDAP Over IPC — The use of inter-process communication (IPC) enhances security by eliminating the need to communicate over a network.
  • IPv6 Support — OpenLDAP is compliant with Internet Protocol version 6 (IPv6), the next generation of the Internet Protocol.
  • LDIFv1 Support — OpenLDAP is fully compliant with LDIF version 1.
  • Updated C API — The current C API improves the way programmers can connect to and use LDAP directory servers.
  • Enhanced Standalone LDAP Server — This includes an updated access control system, thread pooling, better tools, and much more.

12.1.1.3. OpenLDAP Server Setup

The typical steps to set up an LDAP server on Fedora are as follows:
  1. Install the OpenLDAP suite. See Section 12.1.2, “Installing the OpenLDAP Suite” for more information on required packages.
  2. Customize the configuration as described in Section 12.1.3, “Configuring an OpenLDAP Server”.
  3. Start the slapd service as described in Section 12.1.5, “Running an OpenLDAP Server”.
  4. Use the ldapadd utility to add entries to the LDAP directory.
  5. Use the ldapsearch utility to verify that the slapd service is accessing the information correctly.

12.1.2. Installing the OpenLDAP Suite

The suite of OpenLDAP libraries and tools is provided by the following packages:
Table 12.1. List of OpenLDAP packages
Package Description
openldap A package containing the libraries necessary to run the OpenLDAP server and client applications.
openldap-clients A package containing the command line utilities for viewing and modifying directories on an LDAP server.
openldap-servers A package containing both the services and utilities to configure and run an LDAP server. This includes the Standalone LDAP Daemon, slapd.
openldap-servers-sql A package containing the SQL support module.

Additionally, the following packages are commonly used along with the LDAP server:
Table 12.2. List of commonly installed additional LDAP packages
Package Description
nss-pam-ldapd A package containing nslcd, a local LDAP name service that allows a user to perform local LDAP queries.
mod_ldap
A package containing the mod_authnz_ldap and mod_ldap modules. The mod_authnz_ldap module is the LDAP authorization module for the Apache HTTP Server. This module can authenticate users' credentials against an LDAP directory, and can enforce access control based on the user name, full DN, group membership, an arbitrary attribute, or a complete filter string. The mod_ldap module contained in the same package provides a configurable shared memory cache, to avoid repeated directory access across many HTTP requests, and also support for SSL/TLS.

To install these packages, use the dnf command in the following form:
dnf install package
For example, to perform the basic LDAP server installation, type the following at a shell prompt as root:
~]# dnf install openldap openldap-clients openldap-servers
Note that you must have superuser privileges (that is, you must be logged in as root) to run this command. For more information on how to install new packages in Fedora, see Section 6.2.4, “Installing Packages”.

12.1.2.1. Overview of OpenLDAP Server Utilities

To perform administrative tasks, the openldap-servers package installs the following utilities along with the slapd service:
Table 12.3. List of OpenLDAP server utilities
Command Description
slapacl Allows you to check the access to a list of attributes.
slapadd Allows you to add entries from an LDIF file to an LDAP directory.
slapauth Allows you to check a list of IDs for authentication and authorization permissions.
slapcat Allows you to pull entries from an LDAP directory in the default format and save them in an LDIF file.
slapdn Allows you to check a list of Distinguished Names (DNs) based on available schema syntax.
slapindex Allows you to re-index the slapd directory based on the current content. Run this utility whenever you change indexing options in the configuration file.
slappasswd Allows you to create an encrypted user password to be used with the ldapmodify utility, or in the slapd configuration file.
slapschema Allows you to check the compliance of a database with the corresponding schema.
slaptest Allows you to check the LDAP server configuration.

For a detailed description of these utilities and their usage, see the corresponding manual pages as referred to in the section called “Installed Documentation”.

Make sure the files have correct owner

Although only root can run slapadd, the slapd service runs as the ldap user. Because of this, the directory server is unable to modify any files created by slapadd. To correct this issue, after running the slapadd utility, type the following at a shell prompt:
chown -R ldap:ldap /var/lib/ldap

Stop slapd before using these utilities

To preserve the data integrity, stop the slapd service before using slapadd, slapcat, or slapindex. You can do so by typing the following at a shell prompt as root:
~]# systemctl stop slapd.service
For more information on how to start, stop, restart, and check the current status of the slapd service, see Section 12.1.5, “Running an OpenLDAP Server”.

12.1.2.2. Overview of OpenLDAP Client Utilities

The openldap-clients package installs the following utilities which can be used to add, modify, and delete entries in an LDAP directory:
Table 12.4. List of OpenLDAP client utilities
Command Description
ldapadd Allows you to add entries to an LDAP directory, either from a file, or from standard input. It is a symbolic link to ldapmodify -a.
ldapcompare Allows you to compare given attribute with an LDAP directory entry.
ldapdelete Allows you to delete entries from an LDAP directory.
ldapexop Allows you to perform extended LDAP operations.
ldapmodify Allows you to modify entries in an LDAP directory, either from a file, or from standard input.
ldapmodrdn Allows you to modify the RDN value of an LDAP directory entry.
ldappasswd Allows you to set or change the password for an LDAP user.
ldapsearch Allows you to search LDAP directory entries.
ldapurl Allows you to compose or decompose LDAP URLs.
ldapwhoami Allows you to perform a whoami operation on an LDAP server.

With the exception of ldapsearch, each of these utilities is more easily used by referencing a file containing the changes to be made rather than typing a command for each entry to be changed within an LDAP directory. The format of such a file is outlined in the man page for each utility.

12.1.2.3. Overview of Common LDAP Client Applications

Although there are various graphical LDAP clients capable of creating and modifying directories on the server, none of them is included in Fedora. Popular applications that can access directories in a read-only mode include Mozilla Thunderbird, Evolution, or Ekiga.

12.1.3. Configuring an OpenLDAP Server

By default, the OpenLDAP configuration is stored in the /etc/openldap/ directory. The following table highlights the most important directories and files within this directory:
Table 12.5. List of OpenLDAP configuration files and directories
Path Description
/etc/openldap/ldap.conf The configuration file for client applications that use the OpenLDAP libraries. This includes ldapadd, ldapsearch, Evolution, etc.
/etc/openldap/slapd.d/ The directory containing the slapd configuration.

Note that OpenLDAP no longer reads its configuration from the /etc/openldap/slapd.conf file. Instead, it uses a configuration database located in the /etc/openldap/slapd.d/ directory. If you have an existing slapd.conf file from a previous installation, you can convert it to the new format by running the following command as root:
~]# slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/
The slapd configuration consists of LDIF entries organized in a hierarchical directory structure, and the recommended way to edit these entries is to use the server utilities described in Section 12.1.2.1, “Overview of OpenLDAP Server Utilities”.

Do not edit LDIF files directly

An error in an LDIF file can render the slapd service unable to start. Because of this, it is strongly advised that you avoid editing the LDIF files within the /etc/openldap/slapd.d/ directly.

12.1.3.1. Changing the Global Configuration

Global configuration options for the LDAP server are stored in the /etc/openldap/slapd.d/cn=config.ldif file. The following directives are commonly used:
olcAllows
The olcAllows directive allows you to specify which features to enable. It takes the following form:
olcAllows: feature
It accepts a space-separated list of features as described in Table 12.6, “Available olcAllows options”. The default option is bind_v2.
Table 12.6. Available olcAllows options
Option Description
bind_v2 Enables the acceptance of LDAP version 2 bind requests.
bind_anon_cred Enables an anonymous bind when the Distinguished Name (DN) is empty.
bind_anon_dn Enables an anonymous bind when the Distinguished Name (DN) is not empty.
update_anon Enables processing of anonymous update operations.
proxy_authz_anon Enables processing of anonymous proxy authorization control.

Example 12.1. Using the olcAllows directive
olcAllows: bind_v2 update_anon

olcConnMaxPending
The olcConnMaxPending directive allows you to specify the maximum number of pending requests for an anonymous session. It takes the following form:
olcConnMaxPending: number
The default option is 100.
Example 12.2. Using the olcConnMaxPending directive
olcConnMaxPending: 100

olcConnMaxPendingAuth
The olcConnMaxPendingAuth directive allows you to specify the maximum number of pending requests for an authenticated session. It takes the following form:
olcConnMaxPendingAuth: number
The default option is 1000.
Example 12.3. Using the olcConnMaxPendingAuth directive
olcConnMaxPendingAuth: 1000

olcDisallows
The olcDisallows directive allows you to specify which features to disable. It takes the following form:
olcDisallows: feature
It accepts a space-separated list of features as described in Table 12.7, “Available olcDisallows options”. No features are disabled by default.
Table 12.7. Available olcDisallows options
Option Description
bind_anon Disables the acceptance of anonymous bind requests.
bind_simple Disables the simple bind authentication mechanism.
tls_2_anon Disables the enforcing of an anonymous session when the STARTTLS command is received.
tls_authc Disallows the STARTTLS command when authenticated.

Example 12.4. Using the olcDisallows directive
olcDisallows: bind_anon

olcIdleTimeout
The olcIdleTimeout directive allows you to specify how many seconds to wait before closing an idle connection. It takes the following form:
olcIdleTimeout: number
This option is disabled by default (that is, set to 0).
Example 12.5. Using the olcIdleTimeout directive
olcIdleTimeout: 180

olcLogFile
The olcLogFile directive allows you to specify a file in which to write log messages. It takes the following form:
olcLogFile: file_name
The log messages are written to standard error by default.
Example 12.6. Using the olcLogFile directive
olcLogFile: /var/log/slapd.log

olcReferral
The olcReferral option allows you to specify a URL of a server to process the request in case the server is not able to handle it. It takes the following form:
olcReferral: URL
This option is disabled by default.
Example 12.7. Using the olcReferral directive
olcReferral: ldap://root.openldap.org

olcWriteTimeout
The olcWriteTimeout option allows you to specify how many seconds to wait before closing a connection with an outstanding write request. It takes the following form:
olcWriteTimeout
This option is disabled by default (that is, set to 0).
Example 12.8. Using the olcWriteTimeout directive
olcWriteTimeout: 180

12.1.3.2. Changing the Database-Specific Configuration

By default, the OpenLDAP server uses Berkeley DB (BDB) as a database back end. The configuration for this database is stored in the /etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif file. The following directives are commonly used in a database-specific configuration:
olcReadOnly
The olcReadOnly directive allows you to use the database in a read-only mode. It takes the following form:
olcReadOnly: boolean
It accepts either TRUE (enable the read-only mode), or FALSE (enable modifications of the database). The default option is FALSE.
Example 12.9. Using the olcReadOnly directive
olcReadOnly: TRUE

olcRootDN
The olcRootDN directive allows you to specify the user that is unrestricted by access controls or administrative limit parameters set for operations on the LDAP directory. It takes the following form:
olcRootDN: distinguished_name
It accepts a Distinguished Name (DN). The default option is cn=Manager,dn=my-domain,dc=com.
Example 12.10. Using the olcRootDN directive
olcRootDN: cn=root,dn=example,dn=com

olcRootPW
The olcRootPW directive allows you to set a password for the user that is specified using the olcRootDN directive. It takes the following form:
olcRootPW: password
It accepts either a plain text string, or a hash. To generate a hash, type the following at a shell prompt:
~]$ slappaswd
New password: 
Re-enter new password: 
{SSHA}WczWsyPEnMchFf1GRTweq2q7XJcvmSxD
Example 12.11. Using the olcRootPW directive
olcRootPW: {SSHA}WczWsyPEnMchFf1GRTweq2q7XJcvmSxD

olcSuffix
The olcSuffix directive allows you to specify the domain for which to provide information. It takes the following form:
olcSuffix: domain_name
It accepts a fully qualified domain name (FQDN). The default option is dc=my-domain,dc=com.
Example 12.12. Using the olcSuffix directive
olcSuffix: dc=example,dc=com

12.1.3.3. Extending Schema

Since OpenLDAP 2.3, the /etc/openldap/slapd.d/ directory also contains LDAP definitions that were previously located in /etc/openldap/schema/. It is possible to extend the schema used by OpenLDAP to support additional attribute types and object classes using the default schema files as a guide. However, this task is beyond the scope of this chapter. For more information on this topic, see http://www.openldap.org/doc/admin/schema.html.

12.1.3.4. Establishing a Secure Connection

OpenLDAP clients and servers can be secured using the Transport Layer Security (TLS) framework. TLS is a cryptographic protocol designed to provide communication security over the network. As noted above, OpenLDAP suite in Fedora uses Mozilla NSS as the TLS implementation.
To establish a secure connection using TLS, obtain the required certificates as described in How do I use TLS/SSL with Mozilla NSS. Then, a number of options must be configured on both the client and the server. At a minimum, a server must be configured with the Certificate Authority (CA) certificates and also its own server certificate and private key. The clients must be configured with the name of the file containing all the trusted CA certificates.
Typically, a server only needs to sign a single CA certificate. A client may want to connect to a variety of secure servers, therefore it is common to specify a list of several trusted CAs in its configuration.
Server Configuration
This section lists global configuration directives for slapd that need to be specified in the /etc/openldap/slapd.d/cn=config.ldif file on an OpenLDAP server in order to establish TLS.
While the old style configuration uses a single file, normally installed as /usr/local/etc/openldap/slapd.conf, the new style uses a slapd backend database to store the configuration. The configuration database normally resides in the /usr/local/etc/openldap/slapd.d/ directory.
The following directives are also valid for establishing SSL. In addition to TLS directives, you need to enable a port dedicated to SSL on the server side – typically it is port 636. To do so, edit the /etc/sysconfig/slapd file and append the ldaps:/// string to the list of URLs specified with the SLAPD_URLS directive.
olcTLSCACertificateFile
The olcTLSCACertificateFile directive specifies the file encoded with Privacy-Enhanced Mail (PEM) schema that contains trusted CA certificates. The directive takes the following form:
olcTLSCACertificateFile: path
Replace path either with a path to the CA certificate file, or, if you use Mozilla NSS, with a certificate name.
olcTLSCACertificatePath
The olcTLSCACertificatePath directive specifies the path to a directory containing individual CA certificates in separate files. This directory must be specially managed with the OpenSSL c_rehash utility that generates symbolic links with the hashed names that point to the actual certificate files. In general, it is simpler to use the olcTLSCACertificateFile directive instead.
If Mozilla NSS is used, olcTLSCACertificatePath accepts a path to the Mozilla NSS database (as shown in Example 12.13, “Using olcTLSCACertificatePath with Mozilla NSS”). In such a case, c_rehash is not needed.
The directive takes the following form:
olcTLSCACertificatePath: path
Replace path with a path to the directory containing the CA certificate files, or with a path to a Mozilla NSS database file.
Example 12.13. Using olcTLSCACertificatePath with Mozilla NSS
With Mozilla NSS, the olcTLSCACertificatePath directive specifies the path of the directory containing the NSS certificate and key database files. For example:
olcTLSCACertificatePath: sql:/home/nssdb/sharednssdb
The certutil command is used to add a CA certificate to these NSS database files:
certutil -d sql:/home/nssdb/sharednssdb -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 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, 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.

olcTLSCertificateFile
The olcTLSCertificateFile directive specifies the file that contains the slapd server certificate. The directive takes the following form:
olcTLSCertificateFile: path
Replace path with a path to the slapd server certificate file, or, if you use Mozilla NSS, with a certificate name.
Example 12.14. Using olcTLSCertificateFile with Mozilla NSS
When using Mozilla NSS with certificate and key database files specified with the olcTLSCACertificatePath directive, olcTLSCertificateFile is used to specify the name of the certificate to use. First, execute the following command to view a list of certificates available in your NSS database file:
certutil -d sql:/home/nssdb/sharednssdb -L
Select a certificate from the list and pass its name to olcTLSCertificateFile. For example:
olcTLSCertificateFile slapd_cert

olcTLSCertificateKeyFile
The olcTLSCertificateKeyFile directive specifies the file that contains the private key that matches the certificate stored in the file specified with olcTLSCertificateFile. Note that the current implementation does not support encrypted private keys, and therefore the containing file must be sufficiently protected. The directive takes the following form:
olcTLSCertificateKeyFile: path
Replace path with a path to the private key file if you use PEM certificates. When using Mozilla NSS, path stands for the name of a file that contains the password for the key for the certificate specified with the olcTLSCertificateFile directive (see Example 12.15, “Using olcTLSCertificateKeyFile with Mozilla NSS”).
Example 12.15. Using olcTLSCertificateKeyFile with Mozilla NSS
When using Mozilla NSS, this directive specifies the name of a file that contains the password for the key for the certificate specified with olcTLSCertificateFile:
olcTLSCertificateKeyFile: slapd_cert_key
The modutil command can be used to turn off password protection or to change the password for NSS database files. For example:
modutil -dbdir sql:/home/nssdb/sharednssdb -changepw

Client Configuration
Specify the following directives in the /etc/openldap/ldap.conf configuration file on the client system. Most of these directives are parallel to the server configuration options. Directives in/etc/openldap/ldap.conf are configured on a system-wide basis, however, individual users may override them in their ~/.ldaprc files.
The same directives can be used to establish an SSL connection. The ldaps:// string must be used instead of ldap:// in OpenLDAP commands such as ldapsearch. This forces commands to use the default port for SSL, port 636, configured on the server.
TLS_CACERT
The TLS_CACERT directive specifies a file containing certificates for all of the Certificate Authorities the client will recognize. This is equivalent to the olcTLSCACertificateFile directive on a server. TLS_CACERT should always be specified before TLS_CACERTDIR in /etc/openldap/ldap.conf. The directive takes the following form:
TLS_CACERT path
Replace path with a path to the CA certificate file.
TLS_CACERTDIR
The TLS_CACERTDIR directive specifies the path to a directory that contains Certificate Authority certificates in separate files. As with olcTLSCACertificatePath on a server, the specified directory must be managed with the OpenSSL c_rehash utility. Path to Mozilla NSS database file is also accepted, c_rehash is not needed in such case. The directive takes the following form:
TLS_CACERTDIR directory
Replace directory with a path to the directory containing CA certificate files. With Mozilla NSS, directory stands for a path to the certificate or key database file.
TLS_CERT
The TLS_CERT specifies the file that contains a client certificate. This directive can only be specified in a user's ~/.ldaprc file. With Mozilla NSS, this directive specifies the name of the certificate to be chosen from the database specified with the aforementioned TLS_CACERTDIR directive. The directive takes the following form:
TLS_CERT path
Replace path with a path to the client certificate file, or with a name of a certificate from the NSS database.
TLS_KEY
The TLS_KEY specifies the file that contains the private key that matches the certificate stored in the file specified with the TLS_CERT directive. As with olcTLSCertificateFile on a server, encrypted key files are not supported, so the file itself must be carefully protected. This option is only configurable in a user's ~/.ldaprc file.
When using Mozilla NSS, TLS_KEY specifies the name of a file that contains the password for the private key that protects the certificate specified with the TLS_CERT directive. Similarly to the olcTLSCertificateKeyFile directive on a server (see Example 12.15, “Using olcTLSCertificateKeyFile with Mozilla NSS”), you can use the modutil command to manage this password.
The TLS_KEY directive takes the following form:
TLS_KEY path
Replace path with a path to the client certificate file or with a name of the password file in the NSS database.

12.1.3.5. Setting Up Replication

Replication is the process of copying updates from one LDAP server (provider) to one or more other servers or clients (consumers). A provider replicates directory updates to consumers, the received updates can be further propagated by the consumer to other servers, so a consumer can also act simultaneously as a provider. Also, a consumer does not have to be an LDAP server, it may be just an LDAP client. In OpenLDAP, you can use several replication modes, most notable are mirror and sync. For more information on OpenLDAP replication modes, see the OpenLDAP Software Administrator's Guide installed with openldap-servers package (see the section called “Installed Documentation”).
To enable a chosen replication mode, use one of the following directives in /etc/openldap/slapd.d/ on both provider and consumers.
olcMirrorMode
The olcMirrorMode directive enables the mirror replication mode. It takes the following form:
olcMirrorMode on
This option needs to be specified both on provider and consumers. Also a serverID must be specified along with syncrepl options. Find a detailed example in the 18.3.4. MirrorMode section of the OpenLDAP Software Administrator's Guide (see the section called “Installed Documentation”).
olcSyncrepl
The olcSyncrepl directive enables the sync replication mode. It takes the following form:
olcSyncrepl on
The sync replication mode requires a specific configuration on both the provider and the consumers. This configuration is thoroughly described in the 18.3.1. Syncrepl section of the OpenLDAP Software Administrator's Guide (see the section called “Installed Documentation”).

12.1.3.6. Loading Modules and Backends

You can enhance the slapd service with dynamically loaded modules. Support for these modules must be enabled with the --enable-modules option when configuring slapd. Modules are stored in files with the .la extension:
module_name.la
Backends store or retrieve data in response to LDAP requests. Backends may be compiled statically into slapd, or when module support is enabled, they may be dynamically loaded. In the latter case, the following naming convention is applied:
back_backend_name.la
To load a module or a backend, use the following directive in /etc/openldap/slapd.d/:
olcModuleLoad
The olcModuleLoad directive specifies a dynamically loadable module to load. It takes the following form:
olcModuleLoad: module
Here, module stands either for a file containing the module, or a backend, that will be loaded.

12.1.4. SELinux Policy for Applications Using LDAP

SELinux is an implementation of a mandatory access control mechanism in the Linux kernel. By default, SELinux prevents applications from accessing an OpenLDAP server. To enable authentication through LDAP, which is required by several applications, the allow_ypbind SELinux Boolean needs to be enabled. Certain applications also demand an enabled authlogin_nsswitch_use_ldap Boolean in this scenario. Execute the following commands to enable the aforementioned Booleans:
~]# setsebool -P allow_ypbind=1
~]# setsebool -P authlogin_nsswitch_use_ldap=1
The -P option makes this setting persistent across system reboots. See the Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide for more detailed information about SELinux.

12.1.5. Running an OpenLDAP Server

This section describes how to start, stop, restart, and check the current status of the Standalone LDAP Daemon. For more information on how to manage system services in general, see Chapter 7, Services and Daemons.

12.1.5.1. Starting the Service

To start the slapd service in the current session, type the following at a shell prompt as root:
~]# systemctl start slapd.service
To configure the service to start automatically at the boot time, use the following command as root:
~]# systemctl enable slapd.service
See Chapter 7, Services and Daemons for more information on how to configure services in Fedora.

12.1.5.2. Stopping the Service

To stop the running slapd service in the current session, type the following at a shell prompt as root:
~]# systemctl stop slapd.service
To prevent the service from starting automatically at the boot time, type as root:
~]# systemctl disable slapd.service
rm '/etc/systemd/system/multi-user.target.wants/slapd.service'
See Chapter 7, Services and Daemons for more information on how to configure services in Fedora.

12.1.5.3. Restarting the Service

To restart the running slapd service, type the following at a shell prompt as root:
~]# systemctl restart slapd.service
This stops the service and immediately starts it again. Use this command to reload the configuration.

12.1.5.4. Verifying the Service Status

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

12.1.6. Configuring a System to Authenticate Using OpenLDAP

In order to configure a system to authenticate using OpenLDAP, make sure that the appropriate packages are installed on both LDAP server and client machines. For information on how to set up the server, follow the instructions in Section 12.1.2, “Installing the OpenLDAP Suite” and Section 12.1.3, “Configuring an OpenLDAP Server”. On a client, type the following at a shell prompt as root:
~]# dnf install openldap openldap-clients nss-pam-ldapd

12.1.6.1. Migrating Old Authentication Information to LDAP Format

The migrationtools package provides a set of shell and Perl scripts to help you migrate authentication information into an LDAP format. To install this package, type the following at a shell prompt as root:
~]# dnf install migrationtools
This will install the scripts to the /usr/share/migrationtools/ directory. Once installed, edit the /usr/share/migrationtools/migrate_common.ph file and change the following lines to reflect the correct domain, for example:
# Default DNS domain
$DEFAULT_MAIL_DOMAIN = "example.com";

# Default base
$DEFAULT_BASE = "dc=example,dc=com";
Alternatively, you can specify the environment variables directly on the command line. For example, to run the migrate_all_online.sh script with the default base set to dc=example,dc=com, type:
~]# export DEFAULT_BASE="dc=example,dc=com" \
/usr/share/migrationtools/migrate_all_online.sh
To decide which script to run in order to migrate the user database, see Table 12.8, “Commonly used LDAP migration scripts”.
Table 12.8. Commonly used LDAP migration scripts
Existing Name Service Is LDAP Running? Script to Use
/etc flat files yes migrate_all_online.sh
/etc flat files no migrate_all_offline.sh
NetInfo yes migrate_all_netinfo_online.sh
NetInfo no migrate_all_netinfo_offline.sh
NIS (YP) yes migrate_all_nis_online.sh
NIS (YP) no migrate_all_nis_offline.sh

For more information on how to use these scripts, see the README and the migration-tools.txt files in the /usr/share/doc/migrationtools/ directory.

12.1.7. Additional Resources

The following resources offer additional information on the Lightweight Directory Access Protocol. Before configuring LDAP on your system, it is highly recommended that you review these resources, especially the OpenLDAP Software Administrator's Guide.

Installed Documentation

The following documentation is installed with the openldap-servers package:
  • /usr/share/doc/openldap-servers/guide.html — A copy of the OpenLDAP Software Administrator's Guide.
  • /usr/share/doc/openldap-servers/README.schema — A README file containing the description of installed schema files.
Additionally, there is also a number of manual pages that are installed with the openldap, openldap-servers, and openldap-clients packages:
Client Applications
  • ldapadd(1) — The manual page for the ldapadd command describes how to add entries to an LDAP directory.
  • ldapdelete(1) — The manual page for the ldapdelete command describes how to delete entries within an LDAP directory.
  • ldapmodify(1) — The manual page for the ldapmodify command describes how to modify entries within an LDAP directory.
  • ldapsearch(1) — The manual page for the ldapsearch command describes how to search for entries within an LDAP directory.
  • ldappasswd(1) — The manual page for the ldappasswd command describes how to set or change the password of an LDAP user.
  • ldapcompare(1) — Describes how to use the ldapcompare tool.
  • ldapwhoami(1) — Describes how to use the ldapwhoami tool.
  • ldapmodrdn(1) — Describes how to modify the RDNs of entries.
Server Applications
  • slapd(8C) — Describes command line options for the LDAP server.
Administrative Applications
  • slapadd(8C) — Describes command line options used to add entries to a slapd database.
  • slapcat(8C) — Describes command line options used to generate an LDIF file from a slapd database.
  • slapindex(8C) — Describes command line options used to regenerate an index based upon the contents of a slapd database.
  • slappasswd(8C) — Describes command line options used to generate user passwords for LDAP directories.
Configuration Files
  • ldap.conf(5) — The manual page for the ldap.conf file describes the format and options available within the configuration file for LDAP clients.
  • slapd-config(5) — Describes the format and options available within the /etc/openldap/slapd.d configuration directory.

Online Documentation

http://www.openldap.org/doc/admin24/
The current version of the OpenLDAP Software Administrator's Guide.
http://www.kingsmountain.com/ldapRoadmap.shtml
Jeff Hodges' LDAP Roadmap & FAQ containing links to several useful resources and emerging news concerning the LDAP protocol.
http://www.ldapman.org/articles/
A collection of articles that offer a good introduction to LDAP, including methods to design a directory tree and customizing directory structures.
http://www.padl.com/
A website of developers of several useful LDAP tools.

Chapter 13. 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 Fedora. Additionally, it explains how to use the Printer tool to configure printers.

13.1. Samba

Samba is the standard open source Windows interoperability suite of programs for Linux. It implements the server message block (SMB) protocol. Modern versions of this protocol are also known as the common Internet file system (CIFS) protocol. It allows the networking of Microsoft Windows®, Linux, UNIX, and other operating systems together, enabling access to Windows-based file and printer shares. Samba's use of SMB allows it to appear as a Windows server to Windows clients.

Installing the samba package

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

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

13.1.3. Connecting to a Samba Share

You can use either Nautilus or command line to connect to available Samba shares.
Procedure 13.1. Connecting to a Samba Share Using Nautilus
  1. To view a list of Samba workgroups and domains on your network, select PlacesNetwork from the GNOME panel, and then select the desired network. Alternatively, type smb: in the FileOpen Location bar of Nautilus.
    An icon appears for each available SMB workgroup or domain on the network.
    SMB Workgroups in Nautilus
    SMB Workgroups in Nautilus
    Figure 13.1. SMB Workgroups in Nautilus

  2. Double-click one of the workgroup or domain icon to view a list of computers within the workgroup or domain.
  3. An icon exists for each machine within the workgroup. Double-click on an icon to view the Samba shares on the machine. If a user name and password combination is required, you are prompted for them.
    Alternately, you can also specify the Samba server and sharename in the Location: bar for Nautilus using the following syntax (replace servername and sharename with the appropriate values):
    smb://servername/sharename
Procedure 13.2. Connecting to a Samba Share Using the Command Line
  1. To connect to a Samba share from a shell prompt, type the following command:
    ~]$ smbclient //hostname/sharename -U username
    Replace hostname with the host name or IP address of the Samba server you want to connect to, sharename with the name of the shared directory you want to browse, and username with the Samba user name for the system. Enter the correct password or press Enter if no password is required for the user.
    If you see the smb:\> prompt, you have successfully logged in. Once you are logged in, type help for a list of commands. If you want to browse the contents of your home directory, replace sharename with your user name. If the -U switch is not used, the user name of the current user is passed to the Samba server.
  2. To exit smbclient, type exit at the smb:\> prompt.

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

Installing cifs-utils package

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:
~]# dnf install cifs-utils
For more information on installing packages with DNF, see Section 6.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.

CIFS servers that require plain text passwords

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.

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

13.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/.

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

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

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

Setting up a domain member server

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.

Applying the changes to the configuration

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 7, Services and Daemons for more information regarding this tool.

13.1.7. Samba Server Types and the smb.conf File

Samba configuration is straightforward. All modifications to Samba are done in the /etc/samba/smb.conf configuration file. Although the default smb.conf file is well documented, it does not address complex topics such as LDAP, Active Directory, and the numerous domain controller implementations.
The following sections describe the different ways a Samba server can be configured. Keep in mind your needs and the changes required to the /etc/samba/smb.conf file for a successful configuration.

13.1.7.1. Stand-alone Server

A stand-alone server can be a workgroup server or a member of a workgroup environment. A stand-alone server is not a domain controller and does not participate in a domain in any way. The following examples include several user-level security configurations. For more information on security modes, see Section 13.1.8, “Samba Security Modes”.

Anonymous Read-Only

The following /etc/samba/smb.conf file shows a sample configuration needed to implement anonymous read-only file sharing. Two directives are used to configure anonymous access – map to guest = Bad user and guest account = nobody.
Example 13.2. An Example Configuration of a Anonymous Read-Only Samba Server
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = user
guest account = nobody # default value
map to guest = Bad user

[data]
comment = Documentation Samba Server
path = /export
read only = yes
guest ok = yes

Anonymous Read/Write

The following /etc/samba/smb.conf file shows a sample configuration needed to implement anonymous read/write file sharing. To enable anonymous read/write file sharing, set the read only directive to no. The force user and force group directives are also added to enforce the ownership of any newly placed files specified in the share.

Do not use anonymous read/write servers

Although having an anonymous read/write server is possible, it is not recommended. Any files placed in the share space, regardless of user, are assigned the user/group combination as specified by a generic user (force user) and group (force group) in the /etc/samba/smb.conf file.
Example 13.3. An Example Configuration of a Anonymous Read/Write Samba Server
[global]
workgroup = DOCS
security = user
guest account = nobody # default value
map to guest = Bad user

[data]
comment = Data
path = /export
guest ok = yes
writeable = yes
force user = user
force group = group

Anonymous Print Server

The following /etc/samba/smb.conf file shows a sample configuration needed to implement an anonymous print server. Setting browseable to no as shown does not list the printer in Windows Network Neighborhood. Although hidden from browsing, configuring the printer explicitly is possible. By connecting to DOCS_SRV using NetBIOS, the client can have access to the printer if the client is also part of the DOCS workgroup. It is also assumed that the client has the correct local printer driver installed, as the use client driver directive is set to yes. In this case, the Samba server has no responsibility for sharing printer drivers to the client.
Example 13.4. An Example Configuration of a Anonymous Print Samba Server
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = user
map to guest = Bad user
printing = cups

[printers]
comment = All Printers
path = /var/spool/samba
guest ok = yes
printable = yes
use client driver = yes
browseable = yes

Secure Read/Write File and Print Server

The following /etc/samba/smb.conf file shows a sample configuration needed to implement a secure read/write file and print server. Setting the security directive to user forces Samba to authenticate client connections. Notice the [homes] share does not have a force user or force group directive as the [public] share does. The [homes] share uses the authenticated user details for any files created as opposed to the force user and force group in [public].
Example 13.5. An Example Configuration of a Secure Read/Write File and Print Samba Server
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = user
printcap name = cups
disable spools = yes
show add printer wizard = no
printing = cups

[homes]
comment = Home Directories
valid users = %S
read only = no
browseable = no

[public]
comment = Data
path = /export
force user = docsbot
force group = users
guest ok = yes

[printers]
comment = All Printers
path = /var/spool/samba
printer admin = john, ed, @admins
create mask = 0600
guest ok = yes
printable = yes
use client driver = yes
browseable = yes

13.1.7.2. Domain Member Server

A domain member, while similar to a stand-alone server, is logged into a domain controller (either Windows or Samba) and is subject to the domain's security rules. An example of a domain member server would be a departmental server running Samba that has a machine account on the Primary Domain Controller (PDC). All of the department's clients still authenticate with the PDC, and desktop profiles and all network policy files are included. The difference is that the departmental server has the ability to control printer and network shares.

Active Directory Domain Member Server

To implement an Active Directory domain member server, follow procedure below:
Procedure 13.3. Adding a Member Server to an Active Directory Domain
  1. Create the /etc/samba/smb.conf configuration file on a member server to be added to the Active Directory domain. Add the following lines to the configuration file:
    [global]
    realm = EXAMPLE.COM
    security = ADS
    encrypt passwords = yes
    # Optional. Use only if Samba cannot determine the Kerberos server automatically.
    password server = kerberos.example.com
    With the above configuration, Samba authenticates users for services being run locally but is also a client of the Active Directory. Ensure that your kerberos realm parameter is shown in all caps (for example realm = EXAMPLE.COM). Since Windows 2000/2003/2008 requires Kerberos for Active Directory authentication, the realm directive is required. If Active Directory and Kerberos are running on different servers, the password server directive is required to help the distinction.
  2. Configure Kerberos on the member server. Create the /etc/krb5.conf configuration file with the following content:
    [logging]
     default = FILE:/var/log/krb5libs.log
    
    [libdefaults]
     default_realm = AD.EXAMPLE.COM
     dns_lookup_realm = true
     dns_lookup_kdc = true
     ticket_lifetime = 24h
     renew_lifetime = 7d
     rdns = false
     forwardable = false
    
    [realms]
    # Define only if DNS lookups are not working
    # AD.EXAMPLE.COM = {
    #  kdc = server.ad.example.com
    #  admin_server = server.ad.example.com
    #  master_kdc = server.ad.example.com
    # }
    
    [domain_realm]
    # Define only if DNS lookups are not working
    # .ad.example.com = AD.EXAMPLE.COM
    # ad.example.com = AD.EXAMPLE.COM
    Uncomment the [realms] and [domain_realm] sections if DNS lookups are not working.
    For more information on Kerberos, and the /etc/krb5.conf file, see the Using Kerberos section of the Fedora 24 Managing Single Sign-On and Smart Cards.
  3. To join an Active Directory server, type the following command as root on the member server:
    ~]# net ads join -U administrator%password
    The net command authenticates as Administrator using the NT LAN Manager (NTLM) protocol and creates the machine account. Then net uses the machine account credentials to authenticate with Kerberos.

    The security option

    Since security = ads and not security = user is used, a local password back end such as smbpasswd is not needed. Older clients that do not support security = ads are authenticated as if security = domain had been set. This change does not affect functionality and allows local users not previously in the domain.

Windows NT4-based Domain Member Server

The following /etc/samba/smb.conf file shows a sample configuration needed to implement a Windows NT4-based domain member server. Becoming a member server of an NT4-based domain is similar to connecting to an Active Directory. The main difference is NT4-based domains do not use Kerberos in their authentication method, making the /etc/samba/smb.conf file simpler. In this instance, the Samba member server functions as a pass through to the NT4-based domain server.
Example 13.6. An Example Configuration of Samba Windows NT4-based Domain Member Server
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = domain

[homes]
comment = Home Directories
valid users = %S
read only = no
browseable = no

[public]
comment = Data
path = /export
force user = docsbot
force group = users
guest ok = yes

Having Samba as a domain member server can be useful in many situations. There are times where the Samba server can have other uses besides file and printer sharing. It may be beneficial to make Samba a domain member server in instances where Linux-only applications are required for use in the domain environment. Administrators appreciate keeping track of all machines in the domain, even if not Windows-based. In the event the Windows-based server hardware is deprecated, it is quite easy to modify the /etc/samba/smb.conf file to convert the server to a Samba-based PDC. If Windows NT-based servers are upgraded to Windows 2000/2003/2008 the /etc/samba/smb.conf file is easily modifiable to incorporate the infrastructure change to Active Directory if needed.

Make sure you join the domain before starting Samba

After configuring the /etc/samba/smb.conf file, join the domain before starting Samba by typing the following command as root:
~]# net rpc join -U administrator%password
Note that the -S option, which specifies the domain server host name, does not need to be stated in the net rpc join command. Samba uses the host name specified by the workgroup directive in the /etc/samba/smb.conf file instead of it being stated explicitly.

13.1.7.3. Domain Controller

A domain controller in Windows NT is functionally similar to a Network Information Service (NIS) server in a Linux environment. Domain controllers and NIS servers both host user and group information databases as well as related services. Domain controllers are mainly used for security, including the authentication of users accessing domain resources. The service that maintains the user and group database integrity is called the Security Account Manager (SAM). The SAM database is stored differently between Windows and Linux Samba-based systems, therefore SAM replication cannot be achieved and platforms cannot be mixed in a PDC/BDC environment.
In a Samba environment, there can be only one PDC and zero or more BDCs.

A mixed Samba/Windows domain controller environment

Samba cannot exist in a mixed Samba/Windows domain controller environment (Samba cannot be a BDC of a Windows PDC or vice versa). Alternatively, Samba PDCs and BDCs can coexist.

Primary Domain Controller (PDC) Using tdbsam

The simplest and most common implementation of a Samba PDC uses the new default tdbsam password database back end. Replacing the aging smbpasswd back end, tdbsam has numerous improvements that are explained in more detail in Section 13.1.9, “Samba Account Information Databases”. The passdb backend directive controls which back end is to be used for the PDC.
The following /etc/samba/smb.conf file shows a sample configuration needed to implement a tdbsam password database back end.
Example 13.7. An Example Configuration of Primary Domain Controller (PDC) Using tdbsam
[global]
workgroup = DOCS
netbios name = DOCS_SRV
passdb backend = tdbsam
security = user
add user script = /usr/sbin/useradd -m "%u"
delete user script = /usr/sbin/userdel -r "%u"
add group script = /usr/sbin/groupadd "%g"
delete group script = /usr/sbin/groupdel "%g"
add user to group script = /usr/sbin/usermod -G "%g" "%u"
add machine script = /usr/sbin/useradd -s /bin/false -d /dev/null  -g machines "%u"
# The following specifies the default logon script
# Per user logon scripts can be specified in the user
# account using pdbedit logon script = logon.bat
# This sets the default profile path.
# Set per user paths with pdbedit
logon drive = H:
domain logons = yes
os level = 35
preferred master = yes
domain master = yes

[homes]
	comment = Home Directories
	valid users = %S
	read only = no
	
[netlogon]
	comment = Network Logon Service
	path = /var/lib/samba/netlogon/scripts
	browseable = no
	read only = no
# For profiles to work, create a user directory under the
# path shown.
# mkdir -p /var/lib/samba/profiles/john

[Profiles]
	comment = Roaming Profile Share
	path = /var/lib/samba/profiles
	read only = no
	browseable = no
	guest ok = yes
	profile acls = yes
# Other resource shares ... ...

To provide a functional PDC system which uses tdbsam follow these steps:
  1. Add the root user to the Samba password database. You will be prompted to provide a new Samba password for the root user:
    ~]# smbpasswd -a root
    New SMB password:
  2. Start the smb service:
    ~]# service smb start
  3. Make sure all profile, user, and netlogon directories are created.
  4. Add groups that users can be members of:
    ~]# groupadd -f users
    ~]# groupadd -f nobody
    ~]# groupadd -f ntadmins
  5. Associate the UNIX groups with their respective Windows groups.
    ~]# net groupmap add ntgroup="Domain Users" unixgroup=users
    ~]# net groupmap add ntgroup="Domain Guests" unixgroup=nobody
    ~]# net groupmap add ntgroup="Domain Admins" unixgroup=ntadmins
  6. Grant access rights to a user or a group. For example, to grant the right to add client machines to the domain on a Samba domain controller, to the members to the Domain Admins group, execute the following command:
    ~]# net rpc rights grant 'DOCS\Domain Admins' SetMachineAccountPrivilege -S PDC -U root
Keep in mind that Windows systems prefer to have a primary group which is mapped to a domain group such as Domain Users.
Windows groups and users use the same namespace thus not allowing the existence of a group and a user with the same name like in UNIX.

Limitations of the tdbsam authentication back end

If you need more than one domain controller or have more than 250 users, do not use the tdbsam authentication back end. LDAP is recommended in these cases.

Primary Domain Controller (PDC) with Active Directory

Although it is possible for Samba to be a member of an Active Directory, it is not possible for Samba to operate as an Active Directory domain controller.

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

13.1.8.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 13.4. 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
...

13.1.8.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 13.4, “Configuring Samba Guest Shares” to avoid using the security = share directive.

13.1.9. Samba Account Information Databases

The following is a list different back ends you can use with Samba. Other back ends not listed here may also be available.
Plain Text
Plain text back ends are nothing more than the /etc/passwd type back ends. With a plain text back end, all user names and passwords are sent unencrypted between the client and the Samba server. This method is very insecure and is not recommended for use by any means. It is possible that different Windows clients connecting to the Samba server with plain text passwords cannot support such an authentication method.
smbpasswd
The smbpasswd back end utilizes a plain ASCII text layout that includes the MS Windows LanMan and NT account, and encrypted password information. The smbpasswd back end lacks the storage of the Windows NT/2000/2003 SAM extended controls. The smbpasswd back end is not recommended because it does not scale well or hold any Windows information, such as RIDs for NT-based groups. The tdbsam back end solves these issues for use in a smaller database (250 users), but is still not an enterprise-class solution.
ldapsam_compat
The ldapsam_compat back end allows continued OpenLDAP support for use with upgraded versions of Samba.
tdbsam
The default tdbsam password back end provides a database back end for local servers, servers that do not need built-in database replication, and servers that do not require the scalability or complexity of LDAP. The tdbsam back end includes all of the smbpasswd database information as well as the previously-excluded SAM information. The inclusion of the extended SAM data allows Samba to implement the same account and system access controls as seen with Windows NT/2000/2003/2008-based systems.
The tdbsam back end is recommended for 250 users at most. Larger organizations should require Active Directory or LDAP integration due to scalability and possible network infrastructure concerns.
ldapsam
The ldapsam back end provides an optimal distributed account installation method for Samba. LDAP is optimal because of its ability to replicate its database to any number of servers such as the Red Hat Directory Server or an OpenLDAP Server. LDAP databases are light-weight and scalable, and as such are preferred by large enterprises. Installation and configuration of directory servers is beyond the scope of this chapter. For more information on the Red Hat Directory Server, see the Red Hat Directory Server 9.0 Deployment Guide. For more information on LDAP, see Section 12.1, “OpenLDAP”.
If you are upgrading from a previous version of Samba to 3.0, note that the OpenLDAP schema file (/usr/share/doc/samba-version/LDAP/samba.schema) and the Red Hat Directory Server schema file (/usr/share/doc/samba-version/LDAP/samba-schema-FDS.ldif) have changed. These files contain the attribute syntax definitions and objectclass definitions that the ldapsam back end needs in order to function properly.
As such, if you are using the ldapsam back end for your Samba server, you will need to configure slapd to include one of these schema file. See Section 12.1.3.3, “Extending Schema” for directions on how to do this.

Make sure the openldap-servers package is installed

You need to have the openldap-servers package installed if you want to use the ldapsam back end. To ensure that the package is installed, execute the following command as roots:
~]# dnf install openldap-servers

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

13.1.10.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 13.1.5, “Configuring a Samba Server”).

13.1.10.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 13.8. An Example Configuration of WINS Server
[global]
wins support = yes

Using WINS

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.

13.1.11. Samba with CUPS Printing Support

Samba allows client machines to share printers connected to the Samba server. In addition, Samba also allows client machines to send documents built in Linux to Windows printer shares. Although there are other printing systems that function with Fedora, CUPS (Common UNIX Print System) is the recommended printing system due to its close integration with Samba.

13.1.11.1. Simple smb.conf Settings

The following example shows a very basic /etc/samba/smb.conf configuration for CUPS support:
Example 13.9. An Example Configuration of Samba with CUPS Support
[global]
load printers = yes
printing = cups
printcap name = cups
[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
guest ok = yes
writable = no
printable = yes
printer admin = @ntadmins
[print$]
comment = Printer Drivers Share
path = /var/lib/samba/drivers
write list = ed, john
printer admin = ed, john

Other printing configurations are also possible. To add additional security and privacy for printing confidential documents, users can have their own print spooler not located in a public path. If a job fails, other users would not have access to the file.
The print$ directive contains printer drivers for clients to access if not available locally. The print$ directive is optional and may not be required depending on the organization.
Setting browseable to yes enables the printer to be viewed in the Windows Network Neighborhood, provided the Samba server is set up correctly in the domain or workgroup.

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

13.1.13. 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 Fedora specific, some concepts may apply.
  • https://wiki.samba.org/index.php/User_Documentation — Samba 4.x official 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.

13.2. FTP

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 into the remote host or 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, as well as configuration options for the primary FTP server shipped with Fedora, vsftpd.

13.2.1. The File Transfer Protocol

However, because FTP is so prevalent on the Internet, it is often required to share files to the public. System administrators, therefore, should be aware of the FTP protocol's unique characteristics.

13.2.1.1. Multiple Ports, Multiple Modes

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 to protect 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 resolves 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. See Section 13.2.5.8, “Network Options” for more information about limiting passive ports.

13.2.2. FTP Servers

Fedora ships with two different FTP servers:
  • proftpd - A fast, stable, and highly configurable FTP server.
  • vsftpd — A fast, secure FTP daemon which is the preferred FTP server for Fedora. The remainder of this section focuses on vsftpd.

13.2.2.1.  vsftpd

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 Fedora, 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 run with the minimal privileges required for the task.
  • Tasks requiring elevated privileges are handled by processes with the minimal privilege necessary — By leveraging 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 directory /var/ftp/ 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 below 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 are received over a socket, and the validity of any information from child processes is checked before being acted on.
  • Most interaction with FTP clients is 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 allows the attacker access to the shared files.

13.2.3. Files Installed with vsftpd

The vsftpd RPM installs the daemon (/usr/sbin/vsftpd), its configuration and related files, as well as FTP directories onto the system. The following lists the files and directories related to vsftpd configuration:
  • /etc/rc.d/init.d/vsftpd — The initialization script (initscript) used by the systemctl command to start, stop, or reload vsftpd. See Section 13.2.4, “Starting and Stopping vsftpd for more information about using this script.
  • /etc/pam.d/vsftpd — The Pluggable Authentication Modules (PAM) configuration file for vsftpd. This file specifies the requirements a user must meet to login to the FTP server. For more information on PAM, refer to the Using Pluggable Authentication Modules (PAM) chapter of the Fedora 24 Managing Single Sign-On and Smart Cards guide.
  • /etc/vsftpd/vsftpd.conf — The configuration file for vsftpd. See Section 13.2.5, “ vsftpd Configuration Options” for a list of important options contained within this file.
  • /etc/vsftpd/ftpusers — A list of users not allowed to log into vsftpd. By default, this list includes the root, bin, and daemon users, among others.
  • /etc/vsftpd/user_list — This file can be configured to either deny or allow access to the users listed, depending on whether the userlist_deny directive is set to YES (default) or NO in /etc/vsftpd/vsftpd.conf. If /etc/vsftpd/user_list is used to grant access to users, the usernames listed must not appear in /etc/vsftpd/ftpusers.
  • /var/ftp/ — The directory containing files served by vsftpd. It also contains the /var/ftp/pub/ directory for anonymous users. Both directories are world-readable, but writable only by the root user.

13.2.4. Starting and Stopping vsftpd

The vsftpd RPM installs the /etc/rc.d/init.d/vsftpd script, which can be accessed using the systemctl command.
To start the server, as root type:
systemctl start vsftpd.service
To stop the server, as root type:
systemctl stop vsftpd.service
The restart option is a shorthand way of stopping and then starting vsftpd. This is the most efficient way to make configuration changes take effect after editing the configuration file for vsftpd.
To restart the server, as root type:
systemctl restart vsftpd.service
The condrestart (conditional restart) option only starts vsftpd if it is currently running. This option is useful for scripts, because it does not start the daemon if it is not running.
To conditionally restart the server, as root type:
systemctl condrestart vsftpd.service
By default, the vsftpd service does not start automatically at boot time. To configure the vsftpd service to start at boot time, use a service manager such as systemctl. See Chapter 7, Services and Daemons for more information on how to configure services in Fedora.

13.2.4.1. 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, refer to the Fedora Networking Guide.
Next, the DNS server for the FTP domains must be configured to reference the correct machine. For information about BIND and its configuration files, refer to the Fedora Networking Guide.
If there is more configuration files present in the /etc/vsftpd directory, calling systemctl start vsftpd.service results in the /etc/rc.d/init.d/vsftpd initscript starting the same number of processes as the number of configuration files. Each configuration file must have a unique name in the /etc/vsftpd/ directory and must be readable and writable only by root.

13.2.5.  vsftpd Configuration Options

Although vsftpd may not offer the level of customization other widely available FTP servers have, it offers enough options to fill most administrator's needs. The fact that it is not overly feature-laden limits configuration and programmatic errors.
All configuration of vsftpd is handled by its configuration file, /etc/vsftpd/vsftpd.conf. Each directive is on its own line within the file and follows the following format:
directive=value
For each directive, replace directive with a valid directive and value with a valid value.

Do not use spaces

There must not be any spaces between the directive, equal symbol, and the value in a directive.
Comment lines must be preceded by a hash sign (#) and are ignored by the daemon.
For a complete list of all directives available, refer to the man page for vsftpd.conf.

Securing the vsftpd service

For an overview of ways to secure vsftpd, see the Red Hat Enterprise Linux 7 Security Guide.
The following is a list of some of the more important directives within /etc/vsftpd/vsftpd.conf. All directives not explicitly found or commented out within vsftpd's configuration file are set to their default value.

13.2.5.1. Daemon Options

The following is a list of directives which control the overall behavior of the vsftpd daemon.
  • listen — When enabled, vsftpd runs in stand-alone mode. Fedora sets this value to YES. This directive cannot be used in conjunction with the listen_ipv6 directive.
    The default value is NO.
  • listen_ipv6 — When enabled, vsftpd runs in stand-alone mode, but listens only to IPv6 sockets. This directive cannot be used in conjunction with the listen directive.
    The default value is NO.
  • session_support — When enabled, vsftpd attempts to maintain login sessions for each user through Pluggable Authentication Modules (PAM). For more information, refer to the Using Pluggable Authentication Modules (PAM) chapter of the Red Hat Enterprise Linux 6 Managing Single Sign-On and Smart Cards and the PAM man pages. . If session logging is not necessary, disabling this option allows vsftpd to run with less processes and lower privileges.
    The default value is YES.

13.2.5.2. Log In Options and Access Controls

The following is a list of directives which control the login behavior and access control mechanisms.
  • anonymous_enable — When enabled, anonymous users are allowed to log in. The usernames anonymous and ftp are accepted.
    The default value is YES.
    See Section 13.2.5.3, “Anonymous User Options” for a list of directives affecting anonymous users.
  • banned_email_file — If the deny_email_enable directive is set to YES, this directive specifies the file containing a list of anonymous email passwords which are not permitted access to the server.
    The default value is /etc/vsftpd/banned_emails.
  • banner_file — Specifies the file containing text displayed when a connection is established to the server. This option overrides any text specified in the ftpd_banner directive.
    There is no default value for this directive.
  • cmds_allowed — Specifies a comma-delimited list of FTP commands allowed by the server. All other commands are rejected.
    There is no default value for this directive.
  • deny_email_enable — When enabled, any anonymous user utilizing email passwords specified in the /etc/vsftpd/banned_emails are denied access to the server. The name of the file referenced by this directive can be specified using the banned_email_file directive.
    The default value is NO.
  • ftpd_banner — When enabled, the string specified within this directive is displayed when a connection is established to the server. This option can be overridden by the banner_file directive.
    By default vsftpd displays its standard banner.
  • local_enable — When enabled, local users are allowed to log into the system.
    The default value is YES.
    See Section 13.2.5.4, “Local User Options” for a list of directives affecting local users.
  • pam_service_name — Specifies the PAM service name for vsftpd.
    The default value is ftp. Note, in Fedora, the value is set to vsftpd.
  • The default value is NO. Note, in Fedora, the value is set to YES.
  • userlist_deny — When used in conjunction with the userlist_enable directive and set to NO, all local users are denied access unless the username is listed in the file specified by the userlist_file directive. Because access is denied before the client is asked for a password, setting this directive to NO prevents local users from submitting unencrypted passwords over the network.
    The default value is YES.
  • userlist_enable — When enabled, the users listed in the file specified by the userlist_file directive are denied access. Because access is denied before the client is asked for a password, users are prevented from submitting unencrypted passwords over the network.
    The default value is NO, however under Fedora the value is set to YES.
  • userlist_file — Specifies the file referenced by vsftpd when the userlist_enable directive is enabled.
    The default value is /etc/vsftpd/user_list and is created during installation.

13.2.5.3. Anonymous User Options

The following lists directives which control anonymous user access to the server. To use these options, the anonymous_enable directive must be set to YES.
  • anon_mkdir_write_enable — When enabled in conjunction with the write_enable directive, anonymous users are allowed to create new directories within a parent directory which has write permissions.
    The default value is NO.
  • anon_root — Specifies the directory vsftpd changes to after an anonymous user logs in.
    There is no default value for this directive.
  • anon_upload_enable — When enabled in conjunction with the write_enable directive, anonymous users are allowed to upload files within a parent directory which has write permissions.
    The default value is NO.
  • anon_world_readable_only — When enabled, anonymous users are only allowed to download world-readable files.
    The default value is YES.
  • ftp_username — Specifies the local user account (listed in /etc/passwd) used for the anonymous FTP user. The home directory specified in /etc/passwd for the user is the root directory of the anonymous FTP user.
    The default value is ftp.
  • no_anon_password — When enabled, the anonymous user is not asked for a password.
    The default value is NO.
  • secure_email_list_enable — When enabled, only a specified list of email passwords for anonymous logins are accepted. This is a convenient way to offer limited security to public content without the need for virtual users.
    Anonymous logins are prevented unless the password provided is listed in /etc/vsftpd/email_passwords. The file format is one password per line, with no trailing white spaces.
    The default value is NO.

13.2.5.4. Local User Options

The following lists directives which characterize the way local users access the server. To use these options, the local_enable directive must be set to YES.
  • chmod_enable — When enabled, the FTP command SITE CHMOD is allowed for local users. This command allows the users to change the permissions on files.
    The default value is YES.
  • chroot_list_enable — When enabled, the local users listed in the file specified in the chroot_list_file directive are placed in a chroot jail upon log in.
    If enabled in conjunction with the chroot_local_user directive, the local users listed in the file specified in the chroot_list_file directive are not placed in a chroot jail upon log in.
    The default value is NO.
  • chroot_list_file — Specifies the file containing a list of local users referenced when the chroot_list_enable directive is set to YES.
    The default value is /etc/vsftpd/chroot_list.
  • chroot_local_user — When enabled, local users are change-rooted to their home directories after logging in.
    The default value is NO.

    Avoid enabling the chroot_local_user option

    Enabling chroot_local_user opens up a number of security issues, especially for users with upload privileges. For this reason, it is not recommended.
  • guest_enable — When enabled, all non-anonymous users are logged in as the user guest, which is the local user specified in the guest_username directive.
    The default value is NO.
  • guest_username — Specifies the username the guest user is mapped to.
    The default value is ftp.
  • local_root — Specifies the directory vsftpd changes to after a local user logs in.
    There is no default value for this directive.
  • local_umask — Specifies the umask value for file creation. Note that the default value is in octal form (a numerical system with a base of eight), which includes a "0" prefix. Otherwise the value is treated as a base-10 integer.
    The default value is 022.
  • passwd_chroot_enable — When enabled in conjunction with the chroot_local_user directive, vsftpd change-roots local users based on the occurrence of the /./ in the home directory field within /etc/passwd.
    The default value is NO.
  • user_config_dir — Specifies the path to a directory containing configuration files bearing the name of local system users that contain specific setting for that user. Any directive in the user's configuration file overrides those found in /etc/vsftpd/vsftpd.conf.
    There is no default value for this directive.

13.2.5.5. Directory Options

The following lists directives which affect directories.
  • dirlist_enable — When enabled, users are allowed to view directory lists.
    The default value is YES.
  • dirmessage_enable — When enabled, a message is displayed whenever a user enters a directory with a message file. This message resides within the current directory. The name of this file is specified in the message_file directive and is .message by default.
    The default value is NO. Note, in Fedora, the value is set to YES.
  • force_dot_files — When enabled, files beginning with a dot (.) are listed in directory listings, with the exception of the . and .. files.
    The default value is NO.
  • hide_ids — When enabled, all directory listings show ftp as the user and group for each file.
    The default value is NO.
  • message_file — Specifies the name of the message file when using the dirmessage_enable directive.
    The default value is .message.
  • text_userdb_names — When enabled, text usernames and group names are used in place of UID and GID entries. Enabling this option may slow performance of the server.
    The default value is NO.
  • use_localtime — When enabled, directory listings reveal the local time for the computer instead of GMT.
    The default value is NO.

13.2.5.6. File Transfer Options

The following lists directives which affect directories.
  • download_enable — When enabled, file downloads are permitted.
    The default value is YES.
  • chown_uploads — When enabled, all files uploaded by anonymous users are owned by the user specified in the chown_username directive.
    The default value is NO.
  • chown_username — Specifies the ownership of anonymously uploaded files if the chown_uploads directive is enabled.
    The default value is root.
  • write_enable — When enabled, FTP commands which can change the file system are allowed, such as DELE, RNFR, and STOR.
    The default value is YES.

13.2.5.7. Logging Options

The following lists directives which affect vsftpd's logging behavior.
  • dual_log_enable — When enabled in conjunction with xferlog_enable, vsftpd writes two files simultaneously: a wu-ftpd-compatible log to the file specified in the xferlog_file directive (/var/log/xferlog by default) and a standard vsftpd log file specified in the vsftpd_log_file directive (/var/log/vsftpd.log by default).
    The default value is NO.
  • log_ftp_protocol — When enabled in conjunction with xferlog_enable and with xferlog_std_format set to NO, all FTP commands and responses are logged. This directive is useful for debugging.
    The default value is NO.
  • syslog_enable — When enabled in conjunction with xferlog_enable, all logging normally written to the standard vsftpd log file specified in the vsftpd_log_file directive (/var/log/vsftpd.log by default) is sent to the system logger instead under the FTPD facility.
    The default value is NO.
  • vsftpd_log_file — Specifies the vsftpd log file. For this file to be used, xferlog_enable must be enabled and xferlog_std_format must either be set to NO or, if xferlog_std_format is set to YES, dual_log_enable must be enabled. It is important to note that if syslog_enable is set to YES, the system log is used instead of the file specified in this directive.
    The default value is /var/log/vsftpd.log.
  • xferlog_enable — When enabled, vsftpd logs connections (vsftpd format only) and file transfer information to the log file specified in the vsftpd_log_file directive (/var/log/vsftpd.log by default). If xferlog_std_format is set to YES, file transfer information is logged but connections are not, and the log file specified in xferlog_file (/var/log/xferlog by default) is used instead. It is important to note that both log files and log formats are used if dual_log_enable is set to YES.
    The default value is NO. Note, in Fedora, the value is set to YES.
  • xferlog_file — Specifies the wu-ftpd-compatible log file. For this file to be used, xferlog_enable must be enabled and xferlog_std_format must be set to YES. It is also used if dual_log_enable is set to YES.
    The default value is /var/log/xferlog.
  • xferlog_std_format — When enabled in conjunction with xferlog_enable, only a wu-ftpd-compatible file transfer log is written to the file specified in the xferlog_file directive (/var/log/xferlog by default). It is important to note that this file only logs file transfers and does not log connections to the server.
    The default value is NO. Note, in Fedora, the value is set to YES.

Maintaining compatibility with older log file formats

To maintain compatibility with log files written by the older wu-ftpd FTP server, the xferlog_std_format directive is set to YES under Fedora. However, this setting means that connections to the server are not logged.
To both log connections in vsftpd format and maintain a wu-ftpd-compatible file transfer log, set dual_log_enable to YES.
If maintaining a wu-ftpd-compatible file transfer log is not important, either set xferlog_std_format to NO, comment the line with a hash sign (#), or delete the line entirely.

13.2.5.8. Network Options

The following lists directives which affect how vsftpd interacts with the network.
  • accept_timeout — Specifies the amount of time for a client using passive mode to establish a connection.
    The default value is 60.
  • anon_max_rate — Specifies the maximum data transfer rate for anonymous users in bytes per second.
    The default value is 0, which does not limit the transfer rate.
  • connect_from_port_20 When enabled, vsftpd runs with enough privileges to open port 20 on the server during active mode data transfers. Disabling this option allows vsftpd to run with less privileges, but may be incompatible with some FTP clients.
    The default value is NO. Note, in Fedora, the value is set to YES.
  • connect_timeout — Specifies the maximum amount of time a client using active mode has to respond to a data connection, in seconds.
    The default value is 60.
  • data_connection_timeout — Specifies maximum amount of time data transfers are allowed to stall, in seconds. Once triggered, the connection to the remote client is closed.
    The default value is 300.
  • ftp_data_port — Specifies the port used for active data connections when connect_from_port_20 is set to YES.
    The default value is 20.
  • idle_session_timeout — Specifies the maximum amount of time between commands from a remote client. Once triggered, the connection to the remote client is closed.
    The default value is 300.
  • listen_address — Specifies the IP address on which vsftpd listens for network connections.
    There is no default value for this directive.

    Running multiple copies of vsftpd

    If running multiple copies of vsftpd serving different IP addresses, the configuration file for each copy of the vsftpd daemon must have a different value for this directive. See Section 13.2.4.1, “Starting Multiple Copies of vsftpd for more information about multihomed FTP servers.
  • listen_address6 — Specifies the IPv6 address on which vsftpd listens for network connections when listen_ipv6 is set to YES.
    There is no default value for this directive.

    Running multiple copies of vsftpd

    If running multiple copies of vsftpd serving different IP addresses, the configuration file for each copy of the vsftpd daemon must have a different value for this directive. See Section 13.2.4.1, “Starting Multiple Copies of vsftpd for more information about multihomed FTP servers.
  • listen_port — Specifies the port on which vsftpd listens for network connections.
    The default value is 21.
  • local_max_rate — Specifies the maximum rate data is transferred for local users logged into the server in bytes per second.
    The default value is 0, which does not limit the transfer rate.
  • max_clients — Specifies the maximum number of simultaneous clients allowed to connect to the server when it is running in standalone mode. Any additional client connections would result in an error message.
    The default value is 0, which does not limit connections.
  • max_per_ip — Specifies the maximum of clients allowed to connected from the same source IP address.
    The default value is 0, which does not limit connections.
  • pasv_address — Specifies the IP address for the public facing IP address of the server for servers behind Network Address Translation (NAT) firewalls. This enables vsftpd to hand out the correct return address for passive mode connections.
    There is no default value for this directive.
  • pasv_enable — When enabled, passive mode connects are allowed.
    The default value is YES.
  • pasv_max_port — Specifies the highest possible port sent to the FTP clients for passive mode connections. This setting is used to limit the port range so that firewall rules are easier to create.
    The default value is 0, which does not limit the highest passive port range. The value must not exceed 65535.
  • pasv_min_port — Specifies the lowest possible port sent to the FTP clients for passive mode connections. This setting is used to limit the port range so that firewall rules are easier to create.
    The default value is 0, which does not limit the lowest passive port range. The value must not be lower 1024.
  • pasv_promiscuous — When enabled, data connections are not checked to make sure they are originating from the same IP address. This setting is only useful for certain types of tunneling.

    Avoid enabling the pasv_promiscuous option

    Do not enable this option unless absolutely necessary as it disables an important security feature which verifies that passive mode connections originate from the same IP address as the control connection that initiates the data transfer.
    The default value is NO.
  • port_enable — When enabled, active mode connects are allowed.
    The default value is YES.

13.2.6. Additional Resources

For more information about vsftpd, refer to the following resources.

13.2.6.1. Installed Documentation

  • The /usr/share/doc/vsftpd/ directory — This directory contains a README 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 man pages — There are a number of man pages for the daemon and configuration files. The following lists some of the more important man pages.
    Server Applications
    • man vsftpd — Describes available command line options for vsftpd.
    Configuration Files
    • man vsftpd.conf — Contains a detailed list of options available within the configuration file for vsftpd.
    • man 5 hosts_access — Describes the format and options available within the TCP wrappers configuration files: hosts.allow and hosts.deny.

13.2.6.2. Useful Websites

13.3. Printer Configuration

The Printers configuration 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 previous Fedora version that used CUPS, the upgrade process preserved the configured printers.

Using the CUPS web application or command-line tools

You can perform the same and additional operations on printers directly from the CUPS web application or command line. To access the application, in a web browser, go to http://localhost:631/. For CUPS manuals refer to the links on the Home tab of the web site.

13.3.1. Starting the Printers Configuration Tool

With the Printers configuration tool you can perform various operations on existing printers and set up new printers. You can also use CUPS directly (go to http://localhost:631/ to access the CUPS web application).
To start the Printers configuration tool if using the GNOME desktop, press the Super key to enter the Activities Overview, type Printers, and then press Enter. The Printers configuration 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.
The Printers window depicted in Figure 13.2, “Printers Configuration window” appears.
Printers Configuration window
Printers Configuration window
Figure 13.2. Printers Configuration window

13.3.2. Starting Printer Setup

Printer setup process varies depending on the printer queue type.
If you are setting up a local printer connected with USB, the printer is discovered and added automatically. You will be prompted to confirm the packages to be installed and provide an administrator or the root user password. Local printers connected with other port types and network printers need to be set up manually.
Follow this procedure to start a manual printer setup:
  1. Start the Printers configuration tool (refer to Section 13.3.1, “Starting the Printers Configuration Tool”).
  2. Select Unlock to enable changes to be made. In the Authentication Required box, type an administrator or the root user password and confirm.
  3. Select the plus sign to open the Add a New Printer dialog. Select the printer from the list or enter its address below.

13.3.3. Adding a Local Printer

Follow this procedure to add a local printer connected with other than a serial port:
  1. Open the Add a New Printer dialog (refer to Section 13.3.2, “Starting Printer Setup”).
  2. If the device does not appear automatically, select the port to which the printer is connected in the list on the left (such as Serial Port #1 or LPT #1).
  3. On the right, enter the connection properties:
    for Enter URI
    URI (for example file:/dev/lp0)
    for Serial Port
    Baud Rate
    Parity
    Data Bits
    Flow Control
    Adding a local printer
    Adding a local printer
    Figure 13.3. Adding a local printer

  4. Click Forward.
  5. Select the printer model. See Section 13.3.8, “Selecting the Printer Model and Finishing” for details.

13.3.4. Adding an AppSocket/HP JetDirect printer

Follow this procedure to add an AppSocket/HP JetDirect printer:
  1. Open the Add a New Printer dialog (refer to Section 13.3.1, “Starting the Printers Configuration Tool”).
  2. In the list on the left, select Network PrinterAppSocket/HP JetDirect.
  3. On the right, enter the connection settings:
    Hostname
    Printer host name or IP address.
    Port Number
    Printer port listening for print jobs (9100 by default).
    Adding a JetDirect printer
    Adding a JetDirect Printer
    Figure 13.4. Adding a JetDirect printer

  4. Click Forward.
  5. Select the printer model. See Section 13.3.8, “Selecting the Printer Model and Finishing” for details.

13.3.5. Adding an IPP Printer

An IPP printer is a printer attached to a different system on the same TCP/IP network. The system this printer is attached to may either be running CUPS or simply configured to use IPP.
If a firewall is enabled on the printer server, then the firewall must be configured to allow incoming TCP connections on port 631. Note that the CUPS browsing protocol allows client machines to discover shared CUPS queues automatically. To enable this, the firewall on the client machine must be configured to allow incoming UDP packets on port 631.
Follow this procedure to add an IPP printer:
  1. Open the Printers dialog (refer to Section 13.3.2, “Starting Printer Setup”).
  2. In the list of devices on the left, select Network Printer and Internet Printing Protocol (ipp) or Internet Printing Protocol (https).
  3. On the right, enter the connection settings:
    Host
    The host name of the IPP printer.
    Queue
    The queue name to be given to the new queue (if the box is left empty, a name based on the device node will be used).
    Adding an IPP printer
    Networked IPP Printer
    Figure 13.5. Adding an IPP printer

  4. Optionally, click Verify to detect the printer.
  5. Click Forward to continue.
  6. Select the printer model. See Section 13.3.8, “Selecting the Printer Model and Finishing” for details.

13.3.6. Adding an LPD/LPR Host or Printer

Follow this procedure to add an LPD/LPR host or printer:
  1. Open the New Printer dialog (refer to Section 13.3.2, “Starting Printer Setup”).
  2. In the list of devices on the left, select Network PrinterLPD/LPR Host or Printer.
  3. On the right, enter the connection settings:
    Host
    The host name of the LPD/LPR printer or host.
    Optionally, click Probe to find queues on the LPD host.
    Queue
    The queue name to be given to the new queue (if the box is left empty, a name based on the device node will be used).
    Adding an LPD/LPR printer
    Adding an LPD/LPR Printer
    Figure 13.6. Adding an LPD/LPR printer

  4. Click Forward to continue.
  5. Select the printer model. See Section 13.3.8, “Selecting the Printer Model and Finishing” for details.

13.3.7. Adding a Samba (SMB) printer

Follow this procedure to add a Samba printer:

Installing the samba-client package

Note that in order to add a Samba printer, you need to have the samba-client package installed. You can do so by running, as root:
dnf install samba-client
For more information on installing packages with DNF, refer to Section 6.2.4, “Installing Packages”.
  1. Open the New Printer dialog (refer to Section 13.3.2, “Starting Printer Setup”).
  2. In the list on the left, select Network PrinterWindows Printer via SAMBA.
  3. Enter the SMB address in the smb:// field. Use the format computer name/printer share. In Figure 13.7, “Adding a SMB printer”, the computer name is dellbox and the printer share is r2.
    Adding a SMB printer
    SMB Printer
    Figure 13.7. Adding a SMB printer

  4. Click Browse to see the available workgroups/domains. To display only queues of a particular host, type in the host name (NetBios name) and click Browse.
  5. Select either of the options:
    • Prompt user if authentication is required: user name and password are collected from the user when printing a document.
    • Set authentication details now: provide authentication information now so it is not required later. In the Username field, enter the user name to access the printer. This user must exist on the SMB system, and the user must have permission to access the printer. The default user name is typically guest for Windows servers, or nobody for Samba servers.
  6. Enter the Password (if required) for the user specified in the Username field.

    Be careful when choosing a password

    Samba printer user names and passwords are stored in the printer server as unencrypted files readable by root and the Linux Printing Daemon, lpd. Thus, other users that have root access to the printer server can view the user name and password you use to access the Samba printer.
    Therefore, when you choose a user name and password to access a Samba printer, it is advisable that you choose a password that is different from what you use to access your local Fedora system.
    If there are files shared on the Samba print server, it is recommended that they also use a password different from what is used by the print queue.
  7. Click Verify to test the connection. Upon successful verification, a dialog box appears confirming printer share accessibility.
  8. Click Forward.
  9. Select the printer model. See Section 13.3.8, “Selecting the Printer Model and Finishing” for details.

13.3.8. Selecting the Printer Model and Finishing

Once you have properly selected a printer connection type, the system attempts to acquire a driver. If the process fails, you can locate or search for the driver resources manually.
Follow this procedure to provide the printer driver and finish the installation:
  1. In the window displayed after the automatic driver detection has failed, select one of the following options:
    • Select printer from database — the system chooses a driver based on the selected make of your printer from the list of Makes. If your printer model is not listed, choose Generic.
    • Provide PPD file — the system uses the provided PostScript Printer Description (PPD) file for installation. A PPD file may also be delivered with your printer as being normally provided by the manufacturer. If the PPD file is available, you can choose this option and use the browser bar below the option description to select the PPD file.
    • Search for a printer driver to download — enter the make and model of your printer into the Make and model field to search on OpenPrinting.org for the appropriate packages.
    Selecting a printer brand
    Selecting a printer brand from the printer database brands.
    Figure 13.8. Selecting a printer brand

  2. Depending on your previous choice provide details in the area displayed below:
    • Printer brand for the Select printer from database option.
    • PPD file location for the Provide PPD file option.
    • Printer make and model for the Search for a printer driver to download option.
  3. Click Forward to continue.
  4. If applicable for your option, window shown in Figure 13.9, “Selecting a printer model” appears. Choose the corresponding model in the Models column on the left.

    Selecting a printer driver

    On the right, the recommended printer driver is automatically selected; however, you can select another available driver. The print driver processes the data that you want to print into a format the printer can understand. Since a local printer is attached directly to your computer, you need a printer driver to process the data that is sent to the printer.
    Selecting a printer model
    Selecting a Printer Model with a Driver Menu
    Figure 13.9. Selecting a printer model

  5. Click Forward.
  6. Under the Describe Printer enter a unique name for the printer in the Printer Name field. The printer name can contain letters, numbers, dashes (-), and underscores (_); it must not contain any spaces. You can also use the Description and Location fields to add further printer information. Both fields are optional, and may contain spaces.
    Printer setup
    Printer Setup
    Figure 13.10. Printer setup

  7. Click Apply to confirm your printer configuration and add the print queue if the settings are correct. Click Back to modify the printer configuration.
  8. After the changes are applied, a dialog box appears allowing you to print a test page. Click Print Test Page to print a test page now. Alternatively, you can print a test page later as described in Section 13.3.9, “Printing a Test Page”.

13.3.9. Printing a Test Page

After you have set up a printer or changed a printer configuration, print a test page to make sure the printer is functioning properly:
  1. Right-click the printer in the Printing window and click Properties.
  2. In the Properties window, click Settings on the left.
  3. On the displayed Settings tab, click the Print Test Page button.

13.3.10. Modifying Existing Printers

To delete an existing printer, in the Printer configuration window, select the printer and go to PrinterDelete. Confirm the printer deletion. Alternatively, press the Delete key.
To set the default printer, right-click the printer in the printer list and click the Set As Default button in the context menu.

13.3.10.1. The Settings Page

To change printer driver configuration, double-click the corresponding name in the Printer list and click the Settings label on the left to display the Settings page.
You can modify printer settings such as make and model, print a test page, change the device location (URI), and more.
Settings page
Settings Page
Figure 13.11. Settings page

13.3.10.2. The Policies Page

Click the Policies button on the left to change settings in printer state and print output.
You can select the printer states, configure the Error Policy of the printer (you can decide to abort the print job, retry, or stop it if an error occurs).
You can also create a banner page (a page that describes aspects of the print job such as the originating printer, the user name from the which the job originated, and the security status of the document being printed): click the Starting Banner or Ending Banner drop-down menu and choose the option that best describes the nature of the print jobs (for example, confidential).
13.3.10.2.1. Sharing Printers