Fedora Linux

Servers

with

systemd:

third edition

To Aleina and Larisa

in sync again

Fedora Linux Servers with systemd: third edition

Richard Petersen

        Surfing Turtle Press

          Alameda, CA

          www.surfingturtlepress.com

           Please send inquiries to:   editor@surfingturtlepress.com

              ISBN: 

              ISBN-13:

Copyright Richard Petersen, 2018

All rights reserved

Copyright 2018 by Richard Petersen. All rights reserved. Printed in the United States of America.

     Except as permitted under the Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written permission of the publisher, with the exception that the program listings may be entered, stored, and executed in a computer system, but they may not be reproduced for publication.

     Information has been obtained by Surfing Turtle Press from sources believed to be reliable. However, because of the possibility of human or mechanical error by our sources, Surfing Turtle Press, the author Richard Petersen, or others, Surfing Turtle Press does not guarantee the accuracy, adequacy, or completeness of any information and is not responsible for any errors or omissions or the results obtained from use of such information.

     Limit of Liability and Disclaimer of Warranty: The publisher and the author make no representation or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. The information and code in this book are provided on "as is" basis. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. Surfing Turtle Press and anyone else who has been involved in the creation or production of the included code cannot and do not warrant the performance or results that may be obtained by using the code.

Trademark Acknowledgements

UNIX is a trademark of  The Open Group

Microsoft and MS-DOS are registered trademarks of Microsoft Corporation

IBM and PC are registered trademarks of the International Business Machines Corporation

Red Hat and Fedora are trademarks of Red Hat, Inc.

Doc1_image003and  Doc1_image002 are trademarks of Red Hat, Inc

Fedora and the Infinity design logo are trademarks of Red Hat, Inc

See www.fedoraproject.org/wiki/Logo/ for more information

is a trademark of Surfing Turtle Press

Preface

This book is designed as a server reference for Fedora Linux with systemd. This second edition is based on Fedora Linux 28. Administration tools are covered as well as the underlying configuration files and system implementations. The emphasis is on what administrators will need to know to perform key networking and server tasks. Topics covered include the systemd service manager, the systemd service and target files for each server, server roles, and the FirewallD firewall. Key servers are examined, including Web, FTP, CUPS printing, NFS, and Samba (Windows shares). Network support servers and applications covered include the Squid proxy server, the Domain Name System server, and DHCP.

The book is organized into five parts: system tools, Internet servers, shared resources, network support, and administration topics.

Part 1 focuses on system tools such as the systemd service manager, the FirewallD firewall, and shell scripts. A Getting Started chapter covers the basics of the GNOME desktop, software management, and desktop terminals.

Part 2 examines Internet servers. Configuration and implementation of the Postfix and Sendmail mail server, the vsftpd and ProFTPD FTP servers, and the Apache Web server are covered in detail.

Part 3 deals with servers that provide shared resources on a local network or the Internet. Services examined include the Cups printing server, NFS network file server, the Samba Windows file and printing server, and the GFS distributed file system.

Part 4 covers servers that provide network support such as the Squid proxy server, the Bind Domain Name System (DNS) servers, IPv6 auto-configuration, and DHCP servers.

Part 5 covers administration topics such as basic administration tasks, configuring the shell, and TCP/IP networks.

Overview

Preface

Overview

Contents

Part 1:  System Tools

1. Fedora Linux Introduction

2. Getting Started

3. systemd: unit files and server management

4. Firewalls

5. Shell Variables and Scripts

Part 2:  Internet Servers

6. Mail Servers

7. FTP

8. Web Servers

9. News and Database Services

Part 3:  Shared Resources

10. Print Services

11. Network File Systems and Network Information Service: NFS and NIS

12. Samba

13. Distributed Network File Systems

Part 4: Network Support

14. Proxy Servers: Squid

15. Domain Name System: BIND 9

16. Network Autoconfiguration with IPv6, DHCP 4

Part 5:  Administration Topics

17. Basic System Administration

18. Shell Configuration

19. Administering TCP/IP Networks

Table Listing

Figure Listing

Index

A   B   C   D   E   F   G   H   I   K   L   M   N   O   P   Q   R   S   T   U   V   W   X   Z

Contents

Preface

Overview

Contents

Part 1:  System Tools

1. Fedora Linux Introduction

Fedora Linux

Fedora Documentation

Fedora Servers

Getting Fedora Linux

2. Getting Started

Fedora Server startup

Using the Command Line Interface

Changing the hostname: hostnamectl

Application Documentation

The Man Pages

The Info Pages

Accessing USB drives from the Command line Interface on a Server.

Setting the date and time

Editing files with the command line interface: text editors

Fedora Desktop

Network Connections

Network Information: Dynamic and Static

NetworkManager

Managing Network Connections with nmcli

Desktop Network Configuration using GNOME Settings Wi-Fi and Network tabs

Configuring a network with systemd-networkd

Predictable and unpredictable network device names

Network device path names

Renaming network device names with udev rules

Renaming network device names for systemd-networkd with systemd.link

Managing Software

Managing Software with DNF

GNOME Software (Software)

PackageKit

Updating Fedora

Update with the dnf command

Automatic DNF Updates with dnf-automatic.

Server Roles and rolekit

Terminal Window

Controlled Administrative Access: sudo and su

Running Desktop Applications with Administrative Access

Logging In to the Root User Account Directly

sudo su

su

Root User Password

sudo Configuration

3. systemd: unit files and server management

systemd

systemd basic configuration files

units

unit file syntax

special targets

Modifying unit files: /etc/systemd/system

Drop in files: .d directories

/etc/systemd/system

Execution Environment Options

service unit files

On Demand and Standalone Services (socket)

Path units

Template unit files

Runlevels and Special Targets

systemd and automatically mounting file systems: /etc/fstab

systemd slice and scope units

System V: /etc/rc.d/init.d

Shutdown and Poweroff

Managing Services

Enabling services: starting a service automatically at boot

Managing services manually

Cockpit

The service Command

Extended Internet Services Daemon (xinetd)

4. Firewalls

Dynamic and Static Firewalls: FirewallD and the iptables command

Dynamic Firewall with FirewallD

firewall-config

firewall-cmd

Firewall Rules: Netfilter, NAT, mangle

Modules

Packet Filtering

Chains

Targets

Firewall and NAT Chains

Adding and Changing Rules

IPtables Options

Accepting and Denying Packets: DROP and ACCEPT

User-Defined Chains

ICMP Packets

Controlling Port Access

Packet States: Connection Tracking

Specialized Connection Tracking: ftp, irc, Amanda, tftp.

Network Address Translation (NAT)

Adding NAT Rules

Nat Targets and Chains

Nat Redirection: Transparent Proxies

Packet Mangling: the Mangle Table

Static Firewall Commands

ip6tables

arptables

ebtables

xtables

Static Firewall using iptables

Configuring Static IPtables with system-config-firewall

Saving IPtables rules

IPtables Scripts

An IPtables Script Example: IPv4

Drop Policy

IP Spoofing

Server Access

Firewall Outside Access

Blocking Outside Initiated Access

Local Network Access

Listing Rules

User-Defined Rules

Masquerading Local Networks

Controlling ICMP Packets

Simple LAN Configuration

LAN Configuration with Internet Services on the Firewall System

IP Masquerading

Masquerading Local Networks

Masquerading NAT Rules

Masquerading Selected Hosts

5. Shell Variables and Scripts

Shell Variables

Definition and Evaluation of Variables: =, $, set, unset

Variable Values: Strings

Quoting Strings: Double Quotes, Single Quotes, and Backslashes

Quoting Commands: Single Quotes

Values from Linux Commands: Back Quotes

Shell Scripts: User-Defined Commands

Executing Scripts

Script Arguments

Environment Variables

Shell Environment Variables

Control Structures

Test Operations

Conditional Control Structures

Loop Control Structures

Part 2:  Internet Servers

6. Mail Servers

Mail Transport Agents

Postfix

Postfix Commands

Postfix Configuration: main.cf

Network Parameters

Local Networks

Direct Connections

Masquerading

Virtual Domains and Virtual Accounts

Postfix Greylisting Policy Server

Controlling User and Host Access

Header and Body Checks

Controlling Client, Senders, and Recipients

Sendmail

Aliases and LDAP

Sendmail Configuration

Sendmail Masquerading

Configuring Mail Servers and Mail Clients

Configuring Sendmail for a Simple Network Configuration

Configuring Sendmail for a Centralized Mail Server

Configuring a Workstation with Direct ISP Connection

The Mailer Table

Virtual Domains: virtusertable

Security

Dovecot

Spam: SpamAssassin

Mail Filtering: Amavisd-new

7. FTP

FTP Servers

Available Servers

FTP Users

Anonymous FTP: vsftpd

The FTP User Account: anonymous

FTP Group

Creating New FTP Users

Anonymous FTP Server Directories

Anonymous FTP Files

The Very Secure FTP Server

Running vsftpd

Firewall access

Configuring vsftpd

Enabling Standalone Access

Enabling Login Access

Local User Permissions

Anonymous User Permissions

Logging

Connection Time Limits

Messages

vsftpd Access Controls

Denying Access

User Access

User Restrictions

User Authentication

Command Access

vsftpd Virtual Hosts

vsftpd Virtual Users

Professional FTP Daemon: ProFTPD

install and startup

proftpd.config and .ftpaccess

Authentication

Anonymous Access

Virtual FTP Servers

ProFTPD Server Tools

ftpshut

ftpwho and ftpcount

Using FTP with rsync

Accessing FTP Sites with rsync

Configuring an rsync Server

rsync Mirroring

8. Web Servers

Lighttpd Web Server

Apache Web Server

Linux Apache Installation

Apache Multiprocessing Modules: MPM

Starting and Stopping the Web Server

Apache Configuration

Apache Configuration with system-config-httpd

Apache Configuration Directives

Global Configuration

Multi-Processing Modules (MPM)

Server Configuration

Access Controls

Directory-level Configuration

URL Pathnames

CGI Directory

Mime Types

Automatic Directory Indexing

Authentication

User Web sub-sites in user home directories: UserDir

Log Files

Webalizer

Error log and warning level

Formatting Logs

Generating and Managing Log Files

Virtual Hosting on Apache

IP based virtual hosting

Name-Based Virtual Hosting

Dynamic Virtual Hosting

Interpolated Strings

Logs for Virtual Hosts

Apache Instances

Server Side Includes

PHP

Web Server Security: SSL

NGINX Web Server

9. News and Database Services

News Servers

Database Servers

Relational Database Structure

MariaDB (MySQL)

MariaDB Configuration

Global Configuration:/etc/my.cnf

User Configuration: .my.cnf

MariaDB Tools

MariaDB Management with mysql and mysqladmin

PostgreSQL

Part 3:  Shared Resources

10. Print Services

Printer Services: CUPS

Driverless Printing

Printer Devices and Configuration

Printer Device Files

Spool Directories

Server script

Printer Install and Configuration

Automatic printer detection

Printer URI (Universal Resource Identifier)

GNOME Printers: GNOME Settings

system-config-printer: Printing

CUPS Web Configuration Interface

Remote Printers

Configuring Remote Printers with system-config-printer

Configuring Remote Printers with CUPS Web-based Configuration

Configuring remote printers manually

CUPS Configuration files

cupsd.conf

Location Directives

Default Operation Policy: Limit Directives

cupsctl

printers.conf

subscriptions.conf

cups-files.conf

cups-browsed.conf

CUPS Command Line Print Clients

lpr

lpc

lpq and lpstat

lprm

CUPS Command Line Administrative Tools

lpadmin

lpoptions

cupsenable and cupsdisable

accept and reject

lpinfo

11. Network File Systems and Network Information Service: NFS and NIS

Portmapper and RPC Services

Network File System: NFS

NFS Daemons

NFS Configuration: /etc/exports

NFS Host Entries

NFS Options

NFS User-Level Access

NFS /etc/exports Example

Applying Changes

Manually Exporting File Systems

NFSv4

NFS File and Directory Security with NFS4 Access Lists

Controlling Accessing to NFS Servers

/etc/hosts.allow and /etc/hosts.deny

Portmapper Service

Netfilter Rules

Mounting NFS File Systems: NFS Clients

Mounting NFS Automatically: /etc/fstab

Mounting NFS Manually: mount

Mounting NFS on Demand: autofs

Network Information Service: NIS

NIS Servers

Defining NIS Domain

Setting NIS Server Options

Specifying Shared Files

Creating the NIS Database

Controlling Access

Netgroups

NIS Clients

Specifying the NIS Domain and Server

Accessing the Server

Specifying Configuration Files with nsswitch.conf

12. Samba

Samba Applications

Setting Up Samba

Configuring Samba Access from Windows

Accessing Samba Shares from Windows

User Level Security

smbpasswd

pdbedit

The Samba smb.conf Configuration File

Global Section

Network related options

Logging Options

Standalone Server Options

Domain Members Options

Name Resolution

Printing Options

File System Options

Homes Section

The printer and print$ Sections

Shares

Printers

Variable Substitutions

Testing the Samba Configuration

Samba Public Domain Controller: Samba PDC

Microsoft Domain Security

Essential Samba PDC configuration options

Basic configuration

Domain Logon configuration

Master Browser configuration

Accessing Samba Services with Clients

Accessing Windows Samba Shares from GNOME

smbclient

mount.cifs: mount -t cifs

13. Distributed Network File Systems

Corosync Cluster Engine

Pacemaker

Red Hat Global File System (GFS)

Part 4: Network Support

14. Proxy Servers: Squid

Configuring Client Browsers

Squid server configuration files

The squid.conf File

Proxy Security

Proxy Caches

Logs

15. Domain Name System: BIND 9

DNS Address Translations

Fully Qualified Domain Names

IPv4 Addressing

IPv6 Addressing

Manual Translations: /etc/hosts

DNS Servers

DNS Operation

DNS Clients: Resolvers

Local Area Network Addressing

IPv4 Private Networks

IPv6 Private Networks

Local Network Address Example Using IPv4

BIND

BIND 9

Stopping and Starting the BIND 9 server

Domain Name System Configuration

DNS Zones

DNS Servers Types

Location of Bind 9 Server Files and BIND chroot

named.conf (BIND 9)

The zone Statement

Configuration Statements

The options Statement

The directory Option

The forwarders Option

The notify Option

A simple named.conf Example

The view clause

BIND 9 Caching-Only Server

Resource Records for Zone Files

Resource Record Types

Time To Live Directive and Field: $TTL

Start of Authority: SOA

Name Server: NS

Address Record: A, A6, and AAAA

Mail Exchanger: MX

Aliases: CNAME

Pointer Record: PTR

Host Information: HINFO, RP, MINFO, and TXT

Zone Files

Zone Files for Internet Zones

Directives

SOA Record

Nameserver Record

Address Record

Mail Exchanger Record

Address Record with Host Name

Inherited Names

Alias Records

IPv6 Zone File Example

BIND 9 Reverse Mapping File

IPv4 in-addr.arpa Reverse Mapping Format

IPv6 IP6.ARPA Reverse Mapping Format

IPv6 IP6.INT Reverse Mapping Format

RFC 1912 private address management: localhost

Localhost zone file: named.localhost

Localhost Reverse Mapping: named.loopback

BIND 9 Subdomains and Slaves

Subdomain Zones

Subdomain Records

Slave Servers

Slave Zones

Slave Records

Controlling Transfers

Incremental Zone Transfers

IP Virtual Domains

BIND 9 Cache File

Dynamic Update: DHCP and Journal Files

TSIG Signatures and Updates

Manual Updates: nsupdate

DNS Security: Access Control Lists, TSIG, and DNSSEC

Access Control Lists

Secret Keys

DNSSEC

Zone Keys

DNSSEC Resource Records

Signing Keys

DNSSEC Validation

Dynamic Trust Anchor Management

TSIG Keys

Generating TSIG keys

The Key Statement

Split DNS

Internal and External Split DNS

Configuring Views for separate servers

Split View on a single DNS server using view clauses

Response Policy Zones (DNS RPZ): DNS Firewall

16. Network Autoconfiguration with IPv6, DHCP 4

IPv6 Stateless Autoconfiguration

Generating the Local Address

Generating the Full Address: Router Advertisements

Router Renumbering

DHCP for IPv6 addressing

Linux as an IPv6 Router: radvd

DHCP

DHCP 4

Configuring DHCP Client Hosts

Configuring DHCP for IPv4 and IPv6 addressing

DHCP 4 IPv4 server configuration: /etc/dhcp/dhcpd.conf

Dynamic IPv4 Addresses for DHCP 4

DHCP 4 IPv6 Server Configuration

DHCP 4 Dynamic DNS Updates

DHCP 4 IPv4 Subnetworks

DHCP 4 IPv4 Fixed Addresses

Part 5:  Administration Topics

17. Basic System Administration

Fedora Administration Tools

System Directories

Program Directories

Configuration Directories and Files

Configuration Files: /etc

/etc/sysconfig

System Logs, journals, and journald

Performance Analysis Tools and Processes

Glances

vmstat, free, top, iostat, dstat, and Xload

Frysk

GNOME System Monitor

Ending Processes

Scheduling Tasks: systemd.timers and cron

The crontab Command

Organizing Scheduled Tasks

Running cron Directory Scripts

Anacron

Grand Unified Bootloader (GRUB2)

Referencing the kernel

Dracut options (initramfs RAM file system)

Rescue

Re-installing the boot loader

Network Time Protocol, Chrony

The Chrony server

The chrony.conf configuration file

cronyc

18. Shell Configuration

Shell Initialization and Configuration Files

Configuration Directories and Files

Aliases

Aliasing Commands and Options

Aliasing Commands and Arguments

Aliasing Commands

Controlling Shell Operations

Environment Variables and Subshells: export

Configuring Your Shell with Shell Parameters

Shell Parameter Variables

Using Initialization Files

Your Home Directory: HOME

Command Locations: PATH

Specifying the BASH Environment: BASH_ENV

Configuring the Shell Prompt

Specifying Your News Server

Configuring Your Login Shell: .bash_profile

Exporting Variables

Variable Assignments

Editing Your BASH Profile Script

Manually Re-executing the .bash_profile Script

System Shell Profile Script

Configuring the BASH Shell: .bashrc

The User .bashrc BASH Script

The System /etc/bashrc BASH Script

The BASH Shell Logout File: .bash_logout

19. Administering TCP/IP Networks

TCP/IP Protocol Suite

Zero Configuration Networking: Avahi and Link Local Addressing

IPv4 and IPv6

TCP/IP Network Addresses

IPv4 Network Addresses

Class-Based IP Addressing

Netmask

Classless Interdomain Routing (CIDR)

IPv4 CIDR Addressing

IPv6 CIDR Addressing

Obtaining an IP Address

IPv4 Reserved Addresses

Broadcast Addresses

Gateway Addresses

Name Server Addresses

IPv6 Addressing

IPv6 Address Format

IPv6 Interface Identifiers

IPv6 Address types

IPv6 Unicast Global Addresses

IPv6 Unicast Local Use Addresses: Link-Local and Unique-Local Addresses

IPv6 Multicast Addresses

IPv6 and IPv4 Coexistence Methods

TCP/IP Configuration Files

Identifying Hostnames: /etc/hosts

/etc/resolv.conf

/etc/sysconfig/network-scripts

/etc/services

/etc/protocols

/etc/sysconfig/network

/etc/hostname and hostnamectl

Domain Name System (DNS)

host.conf

/etc/nsswitch.conf: Name Service Switch and authselect

Network Interfaces and Routes: ifconfig and route

Network systemd unit file: network.target

Interface Configuration Scripts: /etc/sysconfig/network-scripts

ifconfig

Routing

IP Aliasing

Monitoring Your Network: ping, netstat, tcpdump, EtherApe, Ettercap, Wireshark, and Nagios

GNOME Network Tools: gnome-nettool

Network Information: ping, finger, traceroute, and host

ping

finger and who

host

traceroute

Ettercap

Wireshark

Capture Options

Wireshark Filters

tcpdump

netstat

Nagios

Table Listing

Figure Listing

Index

A   B   C   D   E   F   G   H   I   K   L   M   N   O   P   Q   R   S   T   U   V   W   X   Z

Part 1:  System Tools

1. Fedora Linux Introduction

2. Getting Started

3. systemd: unit files and server management

4. Firewalls

5. Shell Variables and Scripts

1. Fedora Linux Introduction

Linux consists of the operating system program, referred to as the kernel, originally developed by Linus Torvalds. It has always been distributed with a massive number of software applications, ranging from network servers and security programs to office applications and development tools. Linux has evolved as part of the open source software movement, in which independent programmers joined together to provide free quality software to any user. Linux has become the premier platform for open source software, much of it developed by the Free Software Foundation’s GNU project. Many of these applications are bundled as part of standard Linux distributions. Currently, thousands of open source applications are available for Linux on the Fedora software repository. Most of the administration, server, and desktop applications are incorporated into the Fedora repository, using software packages that are Fedora compliant.

Fedora Linux

The Fedora release is maintained and developed by the Fedora Project and consists entirely of open source software. Development is carried out using contributions from Linux developers, allowing them free rein to promote enhancements and new features. The project is designed to work much like other open source projects, with releases keeping pace with the course of rapid development. The Fedora project features detailed documentation of certain topics like installation and desktop user guides at https://doc.fedoraproject.org (see Table 1-1).

The Fedora logo depicts an f encased in a blue circle. On the desktop's top panel the blue Fedora logo is the icon for the Applications menu. The logo has its own package, fedora-logos. The logo is designed to represent three features of the Linux community and development: freedom, communication, and infinite possibilities - the f for freedom, which melds into the Infinity symbol, both encased in a speech bubble evoking communication (voice). Free and open software with infinite possibilities developed through global communication. The idea is to evoke the spirit and purpose of Linux development as one of infinite freedom given a voice. The logo incorporates the four basic ideals of Fedora: open, free, innovative, and forward looking.  See https://fedoraproject.org/wiki/Logo for more details.

The Fedora versions of Linux are entirely free. You can download the most current version, including betas, from https://getfedora.org/ or https://download.fedoraproject.org. The https://download.fedoraproject.org address will link to the best available mirror for you. You can update Fedora using Software Update (PackageKit) to access the Fedora repository.

Fedora Documentation

Documentation for Fedora can be found at https://docs.fedoraproject.org (see Table 1-1). The Fedora installation guide provides a detailed description of all your install procedures. The Fedora desktop users guide covers basic desktop operations like logging in, using office applications, and accessing the Web. Several dedicated Fedora support sites are available that provide helpful information. The https://fedoraforum.org site is a Fedora Project–sponsored forum for end-user support. Here you can post questions and check responses for common problems. The https://ask.fedoraproject.org site provides HowTo for common questions arranged by category such as how much space to reserve for an installation (install solutions), how iptables works for your firewall (server solutions), and how to install Skype (multimedia solutions).

Web Site

Name

https://fedoraproject.org

Fedora Project

https://getfedora.org

Fedora download page

https://download.fedoraproject.org

Fedora repository, mirror link

https://admin.fedoraproject.org/mirrormanager/

Fedora mirrors list

https://docs.fedoraproject.org

Documentation and support tutorials for Fedora releases.

https://docs.fedoraproject.org/f28/install-guide/index.html

Fedora  Installation guide

https://fedoraproject.org/wiki/Releases/28/ChangeSet

Fedora  Feature list

https://docs.fedoraproject.org/fedora-project/project/fedora-overview.html

Fedora Project Overview

https://fedoraproject.org/wiki/FAQ

Fedora FAQ

https://fedoraforum.org

End-user discussion support forum.

https://ask.fedoraproject.org/

Answers to Fedora questions

https://fedoraproject.org/wiki/Fedora_Project_Wiki

Latest Fedora news and events posted by Fedora developers.

https://www.linuxfoundation.org

The Linux Foundation, Official Linux development.

https://kernel.org

Latest Linux kernels.

https://www.redhat.com

The Red Hat Web site

Table 1-1: Fedora sites

On Fedora, the Firefox Browser is configured with a Fedora Project menu on the bookmark bar for accessing popular documentation and support sites. These include the Fedora Project home page, the Fedora Weekly News, community support from Fedora forums, and Planet Fedora.

Fedora maintains detailed specialized documentation, like information on understanding how udev in implemented or how SELinux is configured. For much of the documentation, you will have to rely on installed documentation in /usr/share/doc or the Man and info pages, as well as the context help button for different applications running on your desktop. Web sites for software like those for GNOME, KDE, and LibreOffice.org will provide extensive applicable documentation.

Red Hat also maintains an extensive library of documentation for Red Hat Enterprise Linux, much of which is applicable to Fedora, https://access.redhat.com/documentation/en-us/. The documentation covers topics like virtualization, the Global File System (GFS), Logical Volume Management (LVM), and the Installation Guide. All the Red Hat documentation is freely available under the GNU General Public License.

Fedora Servers

The Fedora distribution of Linux is available online at numerous FTP sites. The primary download site is https://getfedora.org/. The Web page https://download.fedoraproject.org links to an available mirror for you. Changes and latest features are listed in the official Fedora Release notes, where you can download the current release of Fedora Linux, as well as updates and additional software. The Fedora release notes are located at:

https://docs.fedoraproject.org/f28/release-notes/index.html

Choose your current version and then click on the release notes link. See the Fedora change set for a detailed presentation of new features.

Several key Fedora features are listed here:

Fedora has three versions: workstation, server, and cloud. The server version is optimized for dedicated servers and does not install a desktop interface. You can also install servers on the workstation, but the workstation is not optimized for servers.

The Cockpit management console provides a Web interface for managing both system administration and internet servers on your network.  

The DNF package manager replaces YUM. Use the dnf command in place of yum. Options remain much the same.

systemd replaces SysVinit and Upstart as the system and session manager.  systemd uses unit files located in the /lib/systemd/system and /etc/systemd/system directories to manage service, filesystems, and device. You can use the systemctl or cockpit to run services.

FirewallD is the default firewall using firewall-config and firewall-cmd to manage your firewall. The desktop configuration firewall utility is firewall-config.

Getting Fedora Linux

The Fedora Linux distribution installs a professional-level and very stable Linux system along with the KDE and GNOME GUI interfaces, flexible and easy-to-use system configuration tools, an extensive set of Internet servers, a variety of different multimedia applications, and thousands of Linux applications of all kinds. You can find recent information about the Fedora Project at https://fedoraproject.org.

Fedora now releases three versions: workstation, server, and cloud.  You can install them using a Web browser at https://getfedora.org/.

Instead of using the Web browser for a direct download, you can use a direct download location with another client, like an FTP client. The Fedora DVDs resides within the Fedora subdirectory, under the respective version (Server, Workstation, and Cloud), and then under architecture types (i386 or x86_64), in an iso directory (Fedora/Server/x86_64/iso).

You can directly access a Fedora mirror site by entering the following URL. You would then need to navigate through the releases and 23 directories to find the Fedora directories where the Fedora Sever and Workstation iso images are kept.

https://download.fedoraproject.org

You can also access a specific mirror at the following URL. Here will be listed the current Fedora mirror and their addresses, https://admin.fedoraproject.org/mirrormanager/mirrors/Fedora/28/x86_64.

The installation procedure is much the same as for the Fedora Workstation. See the Installation Guide at:

https://docs.fedoraproject.org/f28/install-guide/index.html

The installation procedure for the server provides a more detailed Installation Summary screen with an additional option for Software Selection, as well as options for Time & Date and Network & Host Name (see Figure 1-1). On the Software Selection screen, the Environment selection for "Fedora Server Edition" lets you add various servers as part of the installation (see Figure 1-2). These include some servers such as the Basic Web Server (Apache), Mail server, and the Windows File Server (Samba), as well as editors you may want. The custom environment provides fewer options without the servers.

Figure 1-1: Installation, Installation Summary

Figure 1-2: Installation, Software Selection

There is also a Configuration screen where you set up your password and create a user (see Figure 1-3).

Figure 1-3: Installation, Configuration

The server version installs Fedora without the Fedora GNOME desktop. You are presented only with a command line interface, removing the overhead of your server hardware running the graphical desktop. You could still use the Fedora workstation as a server if you want, installing server software packages. This approach has the advantage of letting you use the server configuration desktop tools available for many servers, such as the system-config-httpd for the Apache Web server. But for dedicated servers with high demands, you would use the server version.

To install the Fedora servers on the Fedora desktop (workstation), you can first install the Fedora Workstation DVD, and then use dnf to download and install the servers you want.

You can also install desktops on the Fedora server, but the system remains optimized for servers. To install a desktop on the Fedora server version use the dnf group install command  with the name of the desktop in quotes, such as "Fedora Workstation" (or a smaller desktop like "Xfce Desktop", the "Cinnamon Desktop", or even the "MATE Desktop"). Use the dnf group list | more command to list available desktops. To boot to the desktop set the default.target to the graphical.target using the systemctl set-default command. You will need administrative access with the sudo command.

sudo dnf group install "Fedora Workstation"
sudo systemctl set-default graphical.target

To go back to using the command line interface instead of the desktop on the next restart, open a terminal window set the default to the multi-user.target. 

sudo systemctl set-default multi-user.target

2. Getting Started

Using Linux has become an almost intuitive process, with easy-to-use interfaces, including graphical logins and desktops like GNOME and KDE. Even the standard Linux command line interface has become more user-friendly, with editable commands, history lists, and cursor-based tools. To start using Linux, you have to know how to access your Linux system and, once you are on the system, how to execute commands and run applications.

Fedora Server startup

At startup, the GRUB menu is displayed for several seconds at startup, before loading the default operating system automatically. Press an arrow key to have GRUB wait until you have made a selection. Your GRUB menu is displayed as shown in Figure 2-1.

The GRUB menu lists Fedora and the Fedora rescue option, as well as any other operating systems installed on your hard drive. Use the arrow keys to move to the entry you want, and press enter. Press the e key to edit a GRUB entry (see Figure 2-2).

Figure 2-1: Fedora GRUB menu

Figure 2-2: Editing a GRUB menu item

To change a particular line, use the arrow keys to move to the line. You can use the arrow keys to move along the line. The Backspace key will delete characters, and simply typing will insert characters. All changes are temporary. Permanent changes can only be made by directly editing the GURB configuration files: the /etc/default/grub file and those in the /etc/grub.d directory, and then running the sudo update-grub command.

The Fedora server DVD, for efficiency reasons, will not install a desktop interface. Instead, you use the traditional UNIX command line interface, accessing your system from a login prompt and typing commands from your keyboard on a command line.

When you start up, a command line interface is presented. The startup procedure uses tty1, the terminal one device, presenting a command line interface. Fedora uses the systemd login manager, logind, to manage logins and sessions. You can configure login manager options with the /etc/systemd/logind.conf file. You can set options such as the number of terminals (default is 6), the idle action, and hardware key operations, such as the power key. Check the logind.conf man page for details. 

The login prompt prompts you to enter your username. This is the username you set up during installation (see Figure 2-3).

Figure 2-3: Server login

After you enter your username, you will be prompted to enter the password. Once logged in, you can then run commands (see Figure 2-3). Your command line prompt is displayed, waiting for you to enter a command. The command line prompt is a dollar sign ($). In Fedora, your prompt is preceded by the user and the hostname. Both are bounded by a set of brackets.

[richard@localhost]$

To end your session, issue the logout or exit command. This returns you to the login prompt, and Linux waits for another user to log in.

[richard@localhost]$ logout

To, instead, shut down your system from the command line, you enter the poweroff command. This command will log you out and shut down the system. It requires administrative access.

$ sudo poweroff

To perform a reboot from the command line, you can use the reboot command.

sudo reboot

From the login prompt, you can reboot your system with the Ctrl-Alt-Del keys.

Using the Command Line Interface

When using the command line interface, you are given a simple prompt at which you type in a command. Even when you are using a desktop like GNOME, you sometimes need to execute commands on a command line. You can do so in a terminal window, which is accessed from the desktop’s dash’s Accessories category as Terminal.

Linux commands make extensive use of options and arguments. Be careful to place your arguments and options in their correct order on the command line. The format for a Linux command is the command name followed by options, and then by arguments, as shown here:

$ command-name options arguments

An option is a one-letter code preceded by one or two hyphens, which modifies the type of action the command takes. Options and arguments may or may not be optional, depending on the command. For example, the ls command can take an option, -s. The ls command displays a listing of files in your directory, and the -s option adds the size of each file in blocks. You enter the command and its option on the command line as follows:

$ ls -s

If you are uncertain what format and options a command uses, you can check the command syntax quickly by displaying its man page. Most commands have a man page. Just enter the man command with the command name as an argument.

An argument is data the command may need to execute its task. In many cases, this is a filename. An argument is entered as a word on the command line that appears after any options. For example, to display the contents of a file, you can use the more command with the file’s name as its argument. The less or more command used with the filename mydata would be entered on the command line as follows:

$ less mydata

The command line is actually a buffer of text you can edit. Before you press enter to execute the command, you can edit the command on the command line. The editing capabilities provide a way to correct mistakes you may make when typing a command and its options. The backspace key lets you erase the character you just typed (the one to the left of the cursor) and the DEL key lets you erase one character to the right of the cursor. With this character-erasing capability, you can backspace over the entire line if you want, erasing what you entered. ctrl-u erases the whole command line and lets you start over again at the prompt.

You can use the UP-ARROW key to redisplay your last-executed command. You can then re-execute that command, or you can edit it and execute the modified command. This is helpful when you have to repeat certain operations, such as editing the same file. This is also helpful when you have already executed a command you entered incorrectly.

Changing the hostname: hostnamectl

You can use the hostnamectl command to display your current hostname and all information pertaining to it such as the machine ID, the kernel used, the architecture, chassis (type of computer), and the operating system (you can add the status option if you want).

To change the hostname use the set-hostname option and the name you want to give the system.

sudo hostnamectl set-hostname myserver

The name of the system is then displayed as part of the prompt (see Figure 2-4), such as:

[richard@myserver ~]$

Figure 2-4: Server hostname changed

Application Documentation

On your system, the /usr/share/doc directory contains documentation files installed by each application. Within each directory, you can usually find HOW-TO, README, and INSTALL documents for that application. Some documentation will include detailed manuals. Many applications have separate documentation packages, usually with the -doc suffix, like bind9-doc. Such documentation may be located under their package name, instead of their application name, like /usr/share/doc/bind9-doc for the DNS server documentation.

The Man Pages

You can also access the Man pages, which are manuals for Linux commands available from the command line interface, using the man command. Enter man with the command on which you want information. The following example asks for information on the ls command:

$ man ls

Pressing the spacebar key advances you to the next page. Pressing the b key moves you back a page. When you finish, press the q key to quit the Man utility and return to the command line. You activate a search by pressing either the slash (/) or question mark (?). The / searches forward, and the ? searches backward. When you press the /, a line opens at the bottom of your screen, and you then enter a word to search for. Press enter to activate the search. You can repeat the same search by pressing the n key. You needn’t reenter the pattern.

The Info Pages

Online documentation for GNU applications, such as the gcc compiler and the Emacs editor, also exist as info pages. You can also access this documentation by entering the command info. This brings up a special screen listing different GNU applications. The info interface has its own set of commands. You can learn more about it by entering info info at the command prompt. Typing m opens a line at the bottom of the screen where you can enter the first few letters of the application. Pressing enter brings up the info file on that application.

Accessing USB drives from the Command line Interface on a Server.

When you attach a USB drive it is detected automatically, but not mounted. A message will be displayed indicating the device name for the drive. If you have one hard drive, which would be labeled device sda, then the USB device would be sdb. USB drives are normally formatted as vfat file systems. Your file system would be located on the first file system on the USB drive, which would be sdb1 in this example. Use the lsblk command to find out the device name of the USB drive.

To access the USB drive you have to create a directory on which to mount it. Then use the mount command to mount the file system. You only create the directory once. Use the mkdir command to create the directory.

lsblk
mkdir myusb

To mount a USB drive to that directory, enter a mount command with the vfat type, mounting the /dev/sdb1 device to the myusb directory. You have to have administrative access, so you need to use the sudo command.

sudo mount  -t vfat   /dev/sdb1  myusb

You can then access the USB drive by accessing the myusb directory.

$ cd myusb
$ ls

Write operations would still have to be run with administrative access.

sudo cp mydata  myusb

To write whole directories and their subdirectories, you need to add the -R option to cp.

sudo cp -R mydatadir  myusb

Once finished with the USB drive, be sure to first unmount it before removing it.

sudo umount /dev/sdb1

The USB drive's directory cannot be your working directory.

Setting the date and time

You can set the system date and time either manually or by referencing an Internet time server. You could also use your local hardware clock. To set the system time manually, you use the date command. The date command has several options for adjusting both displaying and setting the date and time. Check the date man page for a detailed list, man date. You can set the time with the --set option and a string specifying the date. You use human readable terms for the time string, such as Mon or Monday for the day and Jul or July for the month. Hour, minute, and second can be represented by numbers separated by colons. The following sets the date to July 9, 8:15 AM 2018.

sudo date --set='Monday July 9 08:15 2018'

To just set the time you would enter something like:

sudo date --set='12:15:43'

To access the hardware clock, you use the hwclock command. The command itself will display the hardware clock time.

sudo hwclock

The --hctosys option will set the system clock using the hardware clock's time, and the --systohc option resets the hardware clock using the system time. Use the --set and --date options to set the hardware clock to a certain time.

sudo hwclock --systohc

Editing files with the command line interface: text editors

If you are using the command line interface only, you will often have to edit configuration files directly to configure your system and servers. You will have to use a command-line based editor to perform your editing tasks. Most command line editors provide a screen-based interface that makes displaying and editing a file fairly simple. Two standard command line editors are installed by default on your system, vi and nano. Several common command line text editors are listed in Table 2-1. The commands you use to start the editors are also the editor names, in lower case, like vi for the Vi editor, nano and emacs for Emacs. 

The vi editor is the standard editor used on most Linux and UNIX systems.  It can be very difficult to use by people accustomed to a desktop editor. The nano editor is much easier to use, featuring a screen-based interface that you can navigate with arrow keys. If you do not already know vi, you may want to use nano instead.

The nano editor is a simple screen-based editor that lets you visually edit your file, using arrow and page keys to move around the file.  You use control keys to perform actions.  Ctrl-x will exit and prompt you to save the file, Ctrl-o will save it.

Editor

Description

vi

The Vi editor, difficult to use, considered the standard editor on Linux ad UNIX system, installed by default

nano

Easy to use screen-based editor, installed by default

emacs

Powerful and complex screen-based editor, though easier to use than Vi

joe

Simple screen-based editor similar to Emacs, Universe repository

Table 2-1: Command line interface text editors

Start nano with the nano command. To edit a configuration file, you will need administrative access.  You would start nano with the sudo command. Figure 2-5 shows the nano editor being used to edit the /etc/sysconfig/network-scripts/ifcfg-ens3 file. To edit a configuration file like /etc/sysconfig/network-scripts/ifcfg-ens3 you would enter the following.

sudo nano /etc/sysconfig/network-scripts/ifcfg-ens3

More powerful editors you may find helpful are vim and emacs. You will have to first install them. The vim editor provides a slightly easier interface for vi. Emacs provides an interface similar to nano, but much more complex.

Figure 2-5: Editing with nano

Fedora Desktop

The Fedora desktop uses GNOME as the default user interface, though Fedora also supports KDE (see Figure 2-6).  GNOME uses an overview, accessible from the Activities button (left side of the top bar) to access windows, favorite applications, and workspaces (see Figure 2-7).  Favorite applications are accessible from the dash on the overview (left side). The last favorite opens the applications overview, listing all you applications.  You can search for applications and file from the overview's search box (top, center). 

You can access administration tools from the Applications overview. You can also use the GNOME administration tools. On the GNOME desktop top panel, click on the system area menu (top bar, right side) and select System Settings.

You can access your home folder from Files icon on the dash. A file manager window opens showing your home folder (see Figure 2-8). Your home folder will already have default directories created for commonly used files. These include Pictures, Documents, Music, Videos, and Downloads. Your office applications will automatically save files to the Documents folder by default. Image and photo applications place image files in the Pictures directory. The Desktop folder will hold all files and directories saved to your desktop. When you download a file, it is placed in the Downloads directory.

Figure 2-6: Fedora GNOME desktop

Figure 2-7: GNOME 3 Activities Applications Overview Mode

The file manager window displays several components, including a header bar, which combines the title bar and toolbar, and a sidebar. When you open a new directory, the same window is used to display it, and you can use the forward and back arrows to move through previously opened directories. The header bar displays folder buttons showing your current folder and its parent folders. Your Fedora file system, any other local disks, network storage, and ftp access (Connect to Server) are accessed from the "Other Locations" entry in the sidebar.  You can click on a parent folder to move to it. The GNOME file manager also supports tabs. You can open up several folders in the same file manager window.

Figure 2-8: File manager for home folder

Network Connections

You configure your network connections using network managers. You are two major network managers to choose from: NetworkManager and systemd-networkd.  NetworkManager had both a desktop version and a command line version (nmcli). By default, the older NetworkManager is activated at installation. The systemd-networkd network manager is a new simple manager using systemd configuration files. It requires editing configuration files directly.

Network configuration differs depending on whether you are connected to a local area network (LAN) with an Ethernet card or are using a DSL or ISDN modem, a wireless connection, or a dial-up modem connection. Table 2-2 lists several different network configuration tools.

Network Configuration App

Description

NetworkManager

Configures wireless and wired network connections.

GNOME Settings (Network and Wi-Fi tabs)

GNOME3 Network tool to configure network connections, wired and wireless. Replaces the older network connections editor (nm-connections-editor).

cockpit

Starts and stops servers, including network servers (smb for Samba, httpd for Web, bind for DNS, and nfs for NFS).

system-config-firewall

Sets up a network firewall using FirewallD.

wvdial

PPP modem connection, enter on a command line.

wconfig

Wireless connection, enter on a command line.

Table 2-2: Fedora Network Configuration Tools

Network Information: Dynamic and Static

If you are on a network, you may need to obtain certain information to configure your interface. Most networks now support dynamic configuration using either the older Dynamic Host Configuration Protocol (DHCP) or the new IPv6 Protocol and its automatic address configuration. In this case, you need only check the DHCP entry in most network configuration tools. For IPv6, you would check the Enable IPv6 configuration entry in the system-config-network device configuration window.

If your network does not support DHCP or IPv6 automatic addressing, you must provide detailed information about your connection. Such connections are known as static connections, whereas DCHP and IPv6 connections are dynamic. In a static connection, you need to manually enter your connection information such as your IP address and DNS servers, whereas in a dynamic connection this information is automatically provided to your system by a DHCP server or generated by IPv6 when you connect to the network. For DHCP, a DHCP client on each host will obtain the information from a DHCP server serving that network. IPv6 generates its addresses directly from the device and router information such as the device hardware MAC address.

In addition, if you are using a DSL dynamic, ISDN, or modem connection, you will also have to supply provider, log in, and password information, whether your system is dynamic or static. You may also need to supply specialized information such as DSL or modem compression methods, dialup number, or wireless channels to select.

You can obtain most of your static network information from your network administrator or from your ISP (Internet service provider). You would need the following information:

The device name for your network interface       For LAN and wireless connections, this is network device name, which you can find using the ifconfig or ip l commands. For a modem, DSL, or ISDN connection, this is a PPP device named ppp0 (ippp0 for ISDN). Virtual private network (VPN) connections are also supported.

Hostname       Your computer will be identified by this name on the Internet. Do not use localhost; that name is reserved for special use by your system.

Domain name       This is the name of your network.

The Internet Protocol (IP) address assigned to your machine       This is needed only for static Internet connections. Dynamic connections use the DHCP protocol to automatically assign an IP address to you. Every host on the Internet is assigned an IP address. Traditionally, this address used an IPv4 format consisting of a set of four numbers, separated by periods, which uniquely identifies a single location on the Internet, allowing information from other locations to reach that computer. Networks are now converting to the new IP protocol version 6, IPv6, which uses a new format with a much more complex numbering sequence.

Your network IP address       Static connections only. This address is usually similar to the IP address, but with one or more zeros at the end.

The netmask       Static connections only. This is usually 255.255.255.0 for most networks. If, however, you are part of a large network, check with your network administrator or ISP.

The broadcast address for your network, if available (optional)       Static connections only. Usually, your broadcast address is the same as your IP address with the number 255 added at the end.

The IP address of your network’s gateway computer       Static connections only. This is the computer that connects your local network to a larger one like the Internet.

Name servers       Static connections only. The IP address of the name servers your network uses. These enable the use of URLs.

NIS domain and IP address for an NIS server       Necessary if your network uses an NIS server (optional).

User login and password information       Needed for dynamic DSL, ISDN, and modem connections.

NetworkManager

Network Manager will automatically detect your network connections, both wired and wireless. It is the default method for managing your network connections. Network Manager makes use the automatic device detection capabilities of udev to configure your connections. Should you instead need to configure your network connections manually, you would use GNOME Network, available from wired and wireless entries on the System Status Area menu.

Network Manager is user specific. When a user logs in, it selects the network connection preferred by that user. The first time a user runs NetworkManager, the user can choose from a list of current possible connections. For wired connections, a connection can be started automatically, when the system starts up. Initial settings will be supplied from system-wide configuration. 

Network Manager can configure any network connection. This includes wired, wireless, and all manual connections. Network Interface Connection (NIC cards) hardware is detected using udev. Information provided by Network Manager is made available to other applications over D-Bus.

With multiple wireless access points for Internet connections, a system could have several different network connections to choose from, instead of a single-line connection like DSL or cable. This is particularly true for notebook computers that could access different wireless connections at different locations. Instead of manually configuring a new connection each time one is encountered, the Network Manager tool can automatically configure and select a connection to use.

By default, an Ethernet connection will be preferred if available. For wireless connections, you will need to choose the one you want.

Network Manager is designed to work in the background, providing status information for your connection and switching from one configured connection to another as needed. For initial configuration, it detects as much information as possible about the new connection.

Network Manager operates as a daemon with the name NetworkManager. If no Ethernet connection is available, Network Manager will scan for wireless connections, checking for Extended Service Set Identifiers (ESSIDs). If an ESSID identifies a previously used connection, then it is automatically selected. If several are found, then the most recently used one is chosen. If only a new connection is available, then Network Manager waits for the user to choose one. A connection is selected only if the user is logged in. If an Ethernet connection is later made, then Network Manager will switch to it from wireless.

The Network Manager daemon can be turned on or off using the systemctl command with administrative access (sudo). 

sudo systemctl start NetworkManager
sudo systemctl start NetworkManager
sudo systemctl restart NetworkManager

Managing Network Connections with nmcli

The nmcli command is NetworkManager Command Line Interface command. Most network configuration tasks can be performed by nmcli. The nmcli command manages NetworkManager through a set of objects: general (g), networking (n), radio (r), connection (c), device (d), and agent (a). Each can be referenced using the full name or a unique prefix, such as con for connection or dev for device. The unique prefix can be as short as a single character, such as g for general, c for connections, or d for device. See Table 2-3 for a list of the objects and commonly used options. The nmcli man page provides a complete listing with examples. 

The general object shows the current status of NetworkManager and what kind of devices are enabled. You can limit the information displayed using the -t (terse) and -f (field) options. The STATE field show the connection status, and the CONNECTIVITY field the connection.

$ nmcli general
STATE      CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN   
connected  full          enabled  enabled  enabled  enabled

$ nmcli -t -f STATE general
connected

The connection object references the network connection and the show option displays that information. The following example displays your current connection.

nmcli connection show

Object

Description

general

NetworkManager status and enabled devices. Use the terse (-t) and field (-f) option to limit the information displayed.

networking

Manage networking, use on and off to turn networking on or off, and connectivity for the connection state.

radio

Turns on or off the wireless networking (on or off).  Can turn on or off specific kinds of wireless: wifi, wwan (mobile broadband), and wimax. The all option turns on or off all wireless.

connection

Manage network connections.

show       List connection profiles. With --active show only active connections.
up           Activate a connection
down       Deactivate a connection
add         Add a new connection, specifying type, ifname, con-name (profile).
modify   Edit an existing connection, use + and - to add new values to
                properties
edit        Add a new connection or edit an existing one using the interactive
                 editor
delete    Delete a configured connection (profile)
reload    Reload all connection profiles
load        Reload or load a specific profile
               (use to load a new or modified connection profile)

device

Manage network interfaces (devices).

status                Display device status
show                    Display device information
connect             Connect the device
disconnect       Disconnect the device
delete               Delete a software device, such as a bridge.
wifi                    Display a list of available wifi access points
wifi rescan    Rescan for and display access points
wifi connect  Connect to a wifi network; specify password, wep-key-type,
                            ifname, bssid, and name (profile name)
wimax                 List available WiMAX networks

agent

Run as a Network Manager secret agent or polkit agent.

secret      As a secret agent, nmcli listens for secret requests.
polkit      As a polkit agent it listens for all authorization requests.

Table 2-3: The nmcli objects

You can use c instead of connection and s instead of show. 

$ nmcli c s
NAME        UUID                                  TYPE            DEVICE
enp7s0      f7202f6d-fc66-4b81-8962-69b71202efc0  802-3-ethernet  enp7s0
AT&T LTE 1  65913b39-789a-488c-9559-28ea6341d9e1  gsm             --    

As with the general object, you can limit the fields displayed using the -f option. The following only list the name and type fields

$ nmcli -f name, type c s
NAME        TYPE          
enp7s0      802-3-ethernet
AT&T LTE 1  gsm 

Adding the --active option will only show active connections.

nmcli c s --active

To start and stop a connection (like ifconfig does), use the up and down options.

nmcli con up enp7s0.

Use the device object to manage your network devices. The show and status options provide information about your devices. To check the status of all your network devices use the device object and status options:

nmcli device status
DEVICE  TYPE      STATE         CONNECTION
enp7s0  ethernet  connected     enp7s0    
wlp6s0  wifi      disconnected  --        
lo      loopback  unmanaged     --

You can abbreviate device and status to d and s.

nmcli d s

You also use the device object to connect and disconnect devices. Use the connect or disconnect options with the interface name (ifname) of the device, in this example, enp7s0. With the delete option, you can remove a device.

nmcli device disconnect enp7s0
nmcli device connect enp7s0

To turn networking on or off you use the networking object and the on and off options. Use the connectivity option to check network connectivity. The networking object alone tells you if it is enabled or not.

$ nmcli networking
enabled

$ nmcli networking on

$ nmcli networking connectivity
full

Should you want to just turn on or off the Wifi connection, you would use the radio object. Use wifi, wwan, and wimax for a specific type of wifi connection and the all option for all of them. The radio object alone shows wifi status of all your wifi connection types.

$ nmcli radio
WIFI-HW   WIFI  WWAN-HW  WWAN   
enabled  enabled  enabled  enabled

$ nmcli radio wifi on

$ nmcli radio all off

nmcli Wired Connections

You can use nmcli to add connections, just as you can with the desktop NetworkManager tool. To add a new static connection use the connection object with the add option. Specify the connection's profile name with the con-name option, the interface name with the ifname option, the type, such as ethernet. For a static connection you would add the IP address (ipv4 or ipv6), and the gateway address (gw4 or gw6). For a DHCP connection simply do not list the IP address and gateway options. The profile name can be any name. You could have several profile names for the same network device. For example, for your wireless device, you could have several wireless connection profiles, depending on the different networks you want to connect to. Should you connect your Ethernet device to a different network, you would simply use a different connection profile that you have already set up, instead of manually reconfiguring the connection. If you do not specify a connection name, one is generated and assigned to you. The connection name can be the same as the device name as shown here, but keep in mind that the connection name refers to the profile and the device name refers to the actual device.

$ nmcli c s
NAME        UUID                                  TYPE            DEVICE
enp7s0      f7202f6d-fc66-4b81-8962-69b71202efc0  802-3-ethernet  enp7s0

For a DHCP connection, specify the profile name, connection type, and ifname. The following example creates an Ethernet connection with the profile name "my-wired."

nmcli con add con-name my-wired type ethernet ifname enp7s0

For a static connection add the IP (ip4 or ip6) and gateway (gw4 or gw6) options with their addresses.

nmcli con add con-name my-wired-static ifname enp7s0 type ethernet ip4 192.168.1.0/24 gw4 192.168.1.1

In most cases, the type is Ethernet (wired) or wifi (wireless). Check the nmcli man page for a list of other types, such as gsm, infiniband, vpn, vlan, wimax, and bridge.

You can also add a connection using the interactive editor. Use the edit instead of the add option, and specify the con-name (profile) and connection type.

nmcli con edit type ethernet con-name my-wired

To modify an existing connection, use the modify option. For an IP connection, the property that is changed is referenced as part of the IP settings, in this example, ip4. The IP properties include addresses, gateway, and method (ip4.addresses, ip4.gateway, and ip4.method).

nmcli con mod my-wired ip4.gateway 192.168.1.2

To add or remove a value for a property use the + and - signs as a prefix. To add a DNS server address you would use +ip4.dns. To remove one use -ip4.dns. 

nmcli con mod my-wired +ip4.dns 192.168.1.5

You can also modify a connection using the interactive editor.  Use the edit instead of the modify option with the connection name.

nmcli con edit enp7s0

You are then placed in the interactive editor with an nmcli> prompt and the settings you can change are listed. The help command lists available commands. Use the describe command to show property descriptions.

Use print to show the current value of a property and set to change its value. To see all the properties for a setting, use the print command and the setting name. Once you have made changes, use the save command to effect the changes.

print ipv4
print ipv4.dns
print connection
set ipv4.address 192.168.0.1

The connection edit command can also reference a profile using the id option. The Name field in the connection profile information is the same as the ID. Also, each profile is given a unique system UUID, which can also be used to reference the profile.

Once you are finished editing the connection, enter the quit command to leave the editor.

nmcli Wireless Connections

To see a list of all the available wifi connections in your area, you use the wifi option with the device object. You can further qualify it by interface (if you have more than one) by adding the ifname option, and by BSSID adding the bssid option. 

nmcli device wifi

To connect to a new Wifi network, use the wifi connect option and the SSID.  You can further specify a password, wep-key-type, key, ifname, bssid, name (profile name), and if it is private. If you do not provide a name (profile name), nmcli will generate one for you.

nmcli dev wifi connect surfturtle password mypass wep-key-type wpa ifname wlp6s0 name my-wireless1

To reconnect to a Wifi network for which you have previously set up a connection, use the connection object with the up command and the id option to specify the profile name.

nmcli connection up id my-wireless1

You can also add a new wireless connection using the connection object and the wifi type with the ssid option.

nmcli con add con-name my-wireless2 ifname wlp6s0 type wifi ssid ssidname

Then, to set the encryption type use the modify command to set the sec.key-mgmt property, and for the passphrase set the wifi-sec.psk property.

nmcli con mod my-wirless2 wifi-sec.key-mgmt wpa-psk
nmcli con modify my-wireless2 wifi-sec.psk mypassword

Desktop Network Configuration using GNOME Settings Wi-Fi and Network tabs

On the GNOME Settings dialog there is a Wi-Fi tab for wireless configuration and a Network tab for wired, VPN, and proxy configurations. For Wi-Fi, choose the Choose Wi-Fi Settings from the expanded Wi-Fi entries in the System Status Area, or click the Wi-Fi tab in the Settings dialog, to open the Wi-Fi tab (see Figure 2-9).  

Figure 2-9: Network (System Settings)

On the Wi-Fi tab, an Airplane Mode switch and a list of visible wireless connections are listed to the right. The currently active connection will have a checkmark next to its name. On the top right bar is a switch for turning wireless on and off. A menu to the right of the switch list entries for connections to hidden networks, turning your computer's Wi-Fi hotspot capability, and listing previously accessed Wi-Fi Networks.  

Your current active connection will have a checkmark next to it and a gear button to the right. Click the gear button to display a dialog with tabs for managing the connection with tabs for Details, Security, Identity, Ipv4, Ipv6, and Reset. The Details tab show strength, speed, security methods, IP and hardware addresses, routes, and the DNS server IP address. Security tab displays a menu from which you can choose a security method and a password (see Figure 2-10). On the Identity tab you can specify the SSID name, choose a firewall zone, choose to connect automatically when you log in, and whether to make the connection system wide (available to other users).

Figure 2-10: Wireless configuration

For a wired connection, click the Network tab on GNOME Settings to display lists for Wired, VPN, and Network Proxy. The Wired list shows your current wired connections with on and off switched for each. A plus button at the top right of the Wired list lets you add more wired connections. Next to a connection's switch a gear button is displayed. Clicking the gear button opens a configuration dialog with tabs for Details, Identity, IPv4, IPv6, and Security.

Figure 2-11: Wired Configuration

On the IPv tabs you can configure the wired connection using sections for the Addresses, DNS servers, and Routes. DNS and Routs have a switch for automatic (see Figure 2-11).  Turing the switch off allows you to manually enter a DNS server address or routing information. From the Addresses menu you can also choose to make the connection automatic or manual. When manual, new entries appear that let you enter the address, netmask, and gateway. On the IPv6 tab, the netmask entry is replaced by a prefix entry.

Configuring a network with systemd-networkd

The systemd based network manager called systemd-networkd can currently be used for basic operations. You would use it as a small, fast, and simple alternative to a larger manager such as NetworkManager. systemd is described in detail in Chapter 5. The service, target, and socket files for systemd-networkd are located in the /lib/systemd/system: systemd-networkd.service, systemd-networkd.target, and systemd-networkd.socket. Network resolvconf operations are handled with systemd-resolved.service. User configuration files for systemd-networkd are located in /etc/systemd/network.

In the systemd-networkd.service file several security features are enabled. A capability bounding set (CapabilityBoundingSet) lets you limit kernel capabilities to those specified. The man page for capabilities list the available capabilities. The CAP_NET capabilities limit the networkd service to network operations such as interface configuration, firewall administration, multicasting, sockets, broadcasting, and proxies. The CAP_SET capabilities allow for file and process GID and UIDs. The CAP_CHOWN, CAP_DAC_OVERRIDE, and CAP_FOWNER capabilities deal with bypassing permission checks for files. The CAP_SYS capabilities that provide system administrative capabilities are not included. In addition, the ProtectSystem option (systemd.exec) prevents the service from making any changes to the system (/usr, /boot, and /etc directories are read only for this service). The ProtectHome option makes the /home, /root, and /run/user directories inaccessible. WatchdogSec sets the watchdog timeout for the service. Check the systemd.directives man page for a list of all systemd directives.

systemd-networkd.service

[Unit]
Description=Network Service
Documentation=man:systemd-networkd.service(8)
ConditionCapability=CAP_NET_ADMIN
DefaultDependencies=no
# systemd-udevd.service can be dropped once tuntap is moved to netlink
After=systemd-udevd.service network-pre.target systemd-sysusers.service systemd-sysctl.service
Before=network.target multi-user.target shutdown.target
Conflicts=shutdown.target
Wants=network.target

[Service]
Type=notify
Restart=on-failure
RestartSec=0
ExecStart=!!/usr/lib/systemd/systemd-networkd
WatchdogSec=3min
User=systemd-network
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW
ProtectSystem=strict
ProtectHome=yes
ProtectControlGroups=yes
ProtectKernelModules=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6 AF_PACKET
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount @obsolete @raw-io @reboot @swap
SystemCallArchitectures=native
LockPersonality=yes
RuntimeDirectory=systemd/netif
RuntimeDirectoryPreserve=yes

[Install]
WantedBy=multi-user.target
Also=systemd-networkd.socket
Alias=dbus-org.freedesktop.network1.service
Also=systemd-networkd-wait-online.service

The systemd-networkd.socket file sets systemd.socket options for buffer size (ReceiveBuffer), network link (ListenNetlink), passing credentials (PassCredentials). As a condition for starting the service, the CAP_NET_ADMIN capability needs to be set in the capability bounding set (ConditionCapability). 

systemd-networkd.socket

[Unit]
Description=Network Service Netlink Socket
Documentation=man:systemd-networkd.service(8) man:rtnetlink(7)
ConditionCapability=CAP_NET_ADMIN
DefaultDependencies=no
Before=sockets.target

[Socket]
ReceiveBuffer=8M
ListenNetlink=route 1361
PassCredentials=yes

[Install]
WantedBy=sockets.target

The systemd-resolved.service provides for the resolvconf operations (DNS server information). It has the same capabilities as systemd-neworkd.service, except for the network capabilities.

systemd-resolved.service

[[Unit]
Description=Network Name Resolution
Documentation=man:systemd-resolved.service(8)
Documentation=https://www.freedesktop.org/wiki/Software/systemd/resolved
Documentation=https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
Documentation=https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
DefaultDependencies=no
After=systemd-sysusers.service systemd-networkd.service
Before=network.target nss-lookup.target shutdown.target
Conflicts=shutdown.target
Wants=nss-lookup.target

[Service]
Type=notify
Restart=always
RestartSec=0
ExecStart=!!/usr/lib/systemd/systemd-resolved
WatchdogSec=3min
User=systemd-resolve
CapabilityBoundingSet=CAP_SETPCAP CAP_NET_RAW CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_SETPCAP CAP_NET_RAW CAP_NET_BIND_SERVICE
PrivateTmp=yes
PrivateDevices=yes
ProtectSystem=strict
ProtectHome=yes
ProtectControlGroups=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount @obsolete @raw-io @reboot @swap
SystemCallArchitectures=native
LockPersonality=yes
RuntimeDirectory=systemd/resolve
RuntimeDirectoryPreserve=yes

[Install]
WantedBy=multi-user.target
Alias=dbus-org.freedesktop.resolve1.service

In addition, the systemd-networkd-wait-online.service delays activation of other services until systemd-networkd service comes online.

You configure a network connection for networkd using .network files in the /etc/systemd/network directory. Prefix the filename with a number denoting priority. The 10-my-dhcp.network example sets up a DCHP network connection. The Match section matches on a network device and the Network section configures that connection. You can use Name, Path, or MacAddress Keys to reference the device. Use ifconfig or ip l to find the name of the device. Use this name for the Name entry. You can also specify the Host, or check for Virtualization or the system Architecture. In the Network section, the DHCP key enables DHCP support. You can further specify IPv4 (ipv4) or IPv6 (ipv6) support. 

The following example configures a wired (ethernet) device for DHCP. The name of the device as used in the Name entry was found using ifconfig. In the Network section, the DHCP key is set to yes, turning on DCHP support.

10-my-dhcp.network

[Match]
Name=enp7s0

[Network]
DHCP=yes

You can use the glob * matching character to reference all devices of a certain kind. The en* string will match on all Ethernet (wired) devices. Should your device name change, your .network file will still work on it.

10-my-dhcp.network

[Match]
Name=en*

[Network]
DHCP=yes

A wireless connection with DHCP would use the same entries, but specifying the wireless device for the name.

10-my-wirelss.network

[Match]
Name=wlp6s0

[Network]
DHCP=yes

To connect all your wireless devices, use wl and the * glob matching character, wl*. A wireless connection with DHCP would use the same entries, but specifying the wireless device for the name.

10-my-wirelss.network

[Match]
Name=wl*

[Network]
DHCP=yes

With the Address, Gateway, and DNS keys you can set specific addresses for the computer address, the gateway on your network, and the location of the DNS server. This will set up a static connection, instead of a DHCP one.

10-my-static.network

[Match]
Name=enp7s0

[Network]
Address=192.168.0.15/24
Gateway=192.168.0.1
DNS=192.168.0.1

Additional sections let you add more configuration options. In the Address section, you can add a Broadcast address. The Routes section lets you set source and destination routes. The DHCP section lets you send a hostname and set the MTU transmission limit. If your systems is a DHCP servers, the DHCPSERVER section lets you configure address pools, leases, and DNS support.  The Bridge section configures a bridge network.

To use networkd, you first have to make sure you have disabled Network Manager. These changes are made as the root user. Use sudo or login as the root user (su).

sudo systemctl disable NetworkManager

Then enable systemd-networkd.

sudo systemctl enable systemd-networkd

Also, enable and start systemd-resolved to use the DCHP supplied DNS servers.

sudo systemctl enable systemd-resolved

The /etc/resolv.conf file is a link to /run/resolvconf/resolv.conf, which lists the DNS servers (nameserver) provided by the DCHP server.

You can check the status of the networkd and NetworkManager using systemctl to see which is on.

systemctl status systemd-networkd
systemctl status NetworkManager

You can also use the start, stop, and restart commands on systemd-networkd to start up, stop, and restart networking.

sudo systemctl start systemd-networkd
sudo systemctl stop systemd-networkd
sudo systemctl restart systemd-networkd

If you are running the desktop and choose to use systemd-networkd, you will notice that nm-applet in the panel is no longer running.

Predictable and unpredictable network device names

Network devices now use a predictable naming method that differs from the older naming method. Names are generated based on the specific device referencing the network device type, its hardware connection and slot, and even its function. The traditional network device names used the eth prefix with the number of the device for an Ethernet network device. The name eth0 referred to the first Ethernet connection on your computer. This naming method was considered unpredictable as it did not accurately reference the actual Ethernet device. The old system relied on probing the network driver at boot, and if you're your system had several Ethernet connections, the names could end up being switched, depending you how the startup proceeded. With the current version of systemd udev, the naming uses a predictable method that specifies a particular device. The predictable method references the actual hardware connection on your system.

Name

Description

en

Ethernet

sl

serial line IP (slip)

wl

wlan, wireless local area network

ww

wwan, wireless wide area network (mobile broadband)

p

pci geographical location (pci-e slot)

s

hotplug slot index number

o

onboard cards

f

function (used for cards with more than one port)

u

USB port

i

USB port interface

Table 2-4: Network Interface Device Naming

The name used to reference predictable network device names has a prefix for the type of device followed by several qualifiers such as the type of hardware, the slot used, and the function number. Instead of the older unpredictable name like eth0, the first Ethernet device is referenced by a name like enp7s0. The interface name enp7s0 references an Ethernet (en) connection, at pci slot 7 (p7) with the hotplug slot index number 0 (s0). wlp6s0 is a wireless (wl) connection, at pci slot 6 (p6) with the hotplug slot index number 0 (s0). virvb0  is a virtual (vir) bridge (vb) network interface. Table 2-4 lists predictable naming prefixes. 

Unlike the older unpredictable name, the predictable name will most likely be different for each computer. Predictable network names, along with alternatives, are discussed at: 

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

The naming is carried out by the kernel and is describe in the comment section of the kernel source's systemd/src/udev/udev-bultin-net_id.c file.

Network device path names

The directory /sys/devices lists all your devices in subdirectories, including your network devices. The path to the devices progresses through subdirectories named for the busses connecting the device. To quickly find the full path name, you can us the /sys/class directory instead. For network devices use /sys/class/net. Then use the ls -l command to list the network devices with their links to the full pathname in the /sys/devices directory (the ../.. path references a cd change up two directories (class/net) to the /sys directory). 

$ cd /sys/class/net
$ ls
enp7s0  lo  wlp6s0
$ ls -l
total 0
lrwxrwxrwx 1 root root 0 Feb 19 12:27 enp7s0 -> ../../devices/pci0000:00/0000:00:1c.3/0000:07:00.0/net/enp7s0
lrwxrwxrwx 1 root root 0 Feb 19 12:27 lo -> ../../devices/virtual/net/lo
lrwxrwxrwx 1 root root 0 Feb 19 12:28 wlp6s0 -> ../../devices/pci0000:00/0000:00:1c.2/0000:06:00.0/net/wlp6s0

So the full path name in the /sys/devices directory for enp7s0 is:

/sys/devices/pci0000:00/0000:00:1c.3/0000:07:00.0/net/enp7s0

You can find the pci bus slot used with the lspci command. This command lists all your pci connected devices. In this example, the pci bus slot used 7, which is why the pci part of the name enp7s0 is p7. The s part refers to a hotplug slot, in this example s0.

$ lspci
06:00.0 Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter (rev 01)
07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 07)

Devices have certain properties defined by udev, which manages all devices. Some operations, such as systemd link files, make use these properties. The ID_PATH, ID_NET_NAME_MAC, and INTERFACE properties can be used to identify a device to udev. To display these properties, you use the udevadm command to query the udev database. With the info and -e options, properties of all active devices are displayed. You can pipe (|) this output to a grep command to display only those properties for a given device. In the following example, the properties for the enp7s0 device are listed. Preceding the properties for a given device is a line, beginning (^) with a "P" and ending with the device name. The .* matching characters match all other intervening characters on that line, ^P.*enp7s0.  The -A option displays the specified number of additional lines after that match, -A 22. 

$ udevadm info -e | grep -A 22 ^P.*enp7s0
P: /devices/pci0000:00/0000:00:1c.3/0000:07:00.0/net/enp7s0
E: DEVPATH=/devices/pci0000:00/0000:00:1c.3/0000:07:00.0/net/enp7s0
E: ID_BUS=pci
E: ID_MM_CANDIDATE=1
E: ID_MODEL_FROM_DATABASE=RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller
E: ID_MODEL_ID=0x8136
E: ID_NET_DRIVER=r8169
E: ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
E: ID_NET_NAME_MAC=enx74e6e20ec729
E: ID_NET_NAME_PATH=enp7s0
E: ID_OUI_FROM_DATABASE=Dell Inc.
E: ID_PATH=pci-0000:07:00.0
E: ID_PATH_TAG=pci-0000_07_00_0
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Co., Ltd.
E: ID_VENDOR_ID=0x10ec
E: IFINDEX=2
E: INTERFACE=enp7s0
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/enp7s0
E: TAGS=:systemd:
E: USEC_INITIALIZED=1080179

For certain tasks, such as renaming, you many need to know the MAC address. You can find this with the ip link command, which you can abbreviate to ip l. The MAC address is before the brd string. In this example, the MAC address for enp7s0 is 74:e6:e2:0e:c7:29. The ip link command also provides the MTU (Maximum Transmission Unit) and the current state of the connection.

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 74:e6:e2:0e:c7:29 brd ff:ff:ff:ff:ff:ff
3: wlp6s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 4c:bb:58:22:40:1d brd ff:ff:ff:ff:ff:ff

Renaming network device names with udev rules

If you should change your hardware, like your motherboard with its Ethernet connection, or, if you use an Ethernet card and simply change the slot it is connected to, then the name will change. For firewall rules referencing a particular Ethernet connection, this could be a problem. You can, if you wish, change the name to one of your own choosing, even using the older unpredictable names. This way you would only have to update the name change, rather than all your rules and any other code that references the network device by name.

You can change device name by adding a user udev rule for network device names. Changes made with udev rules work for both NetworkManager and systemd-networkd. In the /etc/udev/rules.d directory, create a file with the .rules extension and prefixed by a number less than 80, such as 70-my-net-names.rules.The .rules files in /etc/udev/rules.d take precedence over those in the udev system directory, /lib/udev/rules.d.

In the udev rule, identify the subsystem  as net (SUBSYSTEM=="net"), the action to take as add (ACTION=="add)), then the MAC address (ATTR[address}, the address attribute). Use ip link to obtain the mac address. The MAC address is also listed as the ID_NET_NAME_MAC entry in the udevadm info output (be sure to remove the prefix and add intervening colons). Use the NAME field to specify the new name for the device. Use the single = operator to make the name assignment.

/etc/udev/rules.d/70-my-net-names.rules

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="74:e6:e2:0e:c7:29", NAME="eth0"

To further specify the device you can add the kernel name (KERNEL) of the device. The kernel name is the INTERFACE entry.

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="74:e6:e2:0e:c7:29", KERNEL=="enp7s0", NAME="eth0"

Renaming network device names for systemd-networkd with systemd.link

The systemd-networkd manager provides an alternate way to change network device names (keep in mind that an udev rule will also work for systemd-networkd). To change the name you would set up a systemd link file in the /etc/systemd/network directory. The systemd.link man page shows how to do this. A systemd link file consists of Match and Link sections. In the Match section you specify the network device, and in the Link section to specify the name you want to give it. The network device can be referenced by its predictable name (Path) or MAC address (MACAddress).

The default systemd link file is /lib/systemd/network/99-default.link. The file had only a Link section which lists policies to use in determining the name. The NamePolicy key lists the policies to be checked, starting with the kernel, then the udev database, udev firmware onboard information, udev hot-plug slot information, and the device path. In most cases, the slot policy is used. The MACAddressPolicy is set to persistent, for devices that have or need fixed MAC addresses.

99-default.link

[Link]
NamePolicy=kernel database onboard slot path
MACAddressPolicy=persistent

To rename a device, you would set up a systemd link file in the /etc/systemd/network directory. The /etc/systemd directory takes precedence over the /lib/systemd directory. A link file consists of a priority number, any name, and the .link extension. Lower numbers have a higher priority. In this example, the network device enp7s0 has its named changed to eth0. The Match section uses the Path key to match on the device path, using the ID_PATH property for the device provided by udev.

You can query the udev database for information on your network device using the udevadm info command and match on the device. An added grep operation for ID_PATH= will display only the ID_PATH property.

$ udevadm info -e | grep -A 22 ^P.*enp7s0 | grep ID_PATH=
E: ID_PATH=pci-0000:07:00.0

For the Path key use the udev ID_PATH value and a * glob matching character for the rest of the path. The Link section uses the Name key to specify the new name. The MacAddressPolicy should be set to persistent, indicating a fixed connection. Start the name of the link file with a number less than 99, so as to take precedence over the 99-default.link file.

10-my-netname.link

[Match]
Path=pci-0000:07:00.0-*

[Link]
Name=eth0
MacAddressPolicy=persistent

Instead of the Path key, you could use the MACAddress key to match on the hardware address of the network device. The MAC address is udev ID_NET_NAME_MAC property without the prefix and with colons separation. The MAC address in this example is 74:e6:e2:0e:c7:29.   You can also use ip link to find the MAC address (the numbers before brd). 

10-my-netname.link

[Match]
MACAddress=74:e6:e2:0e:c7:29

[Link]
Name=eth0
MacAddressPolicy=persistent

Alternatively, you could use the OriginalName key in the Match section instead of the Path. The original name is the udev INTERFACE property, which also the name of the device as displayed by ifconfig.

10-my-netname.link

[Match]
OriginalName=enp7s0*

[Link]
Name=eth0
MacAddressPolicy=persistent

Managing Software

To install software from the desktop you can use PackageKit or GNOME Software.  PackageKit (Packages) is not installed by default and has the name Packages. Keep in mind that to install servers and server tools on the desktop, you may have to use dnf instead of GNOME Software.

Managing Software with DNF

Downloading Fedora software or software from any Fedora repository is a simple matter of using the Dandified YUM (DNF) package manager (https://fedoraproject.org/wiki/Features/DNF). DNF uses many of the same commands and options as YUM, which it replaces. GNOME Software and Packages (PackageKit) provide desktop interfaces for the DNF package manager.

For detailed documentation on the use and configuration of the Apache Web server on Fedora see the Fedora System Administration Guide | Package Management | DNF.

https://docs.fedoraproject.org/f28/system-administrators-guide/package-management/DNF.html

Downloading Fedora software or software from any Fedora repository is a simple matter of using the Dandified YUM (DNF) package manager (https://fedoraproject.org/wiki/Features/DNF). DNF uses many of the same commands and options as YUM, which it replaces. GNOME Software and Packages (PackageKit) provide desktop interfaces for the DNF package manager.

You can use the dnf command, in a terminal window or command-line interface, to access Fedora repositories and install new software. To use the dnf command, enter the dnf command with the install option on a command line. The package will be detected, along with any dependent software, and you will be asked to confirm installation. The download and installation is automatic. The following command installs vsftpd FTP server:

sudo dnf install vsftpd

You can also remove packages, as well as search for packages and list packages by different criteria, such as those for update, those on the repository not yet installed, and those already installed. The following example lists all installed packages:

dnf list installed

The available option shows uninstalled packages.

dnf list available

To quickly to see if a package is available you can use the list command. The list command works on a package name.  Add the asterisk for a pattern search.

dnf list vsftpd
dn list *ftp*
dnf list bind*

To search package descriptions, use the search command and a pattern.

dnf search wine

For details about a package, use the repoquery command with the -i option. With the -l option is lists the files the package will install.

dnf repoquery -i vsftpd
dnf repoquery -l vsftpd

When removing a package, in some rare cases, the entire GNOME desktop, along with the GDM and Packages, could be selected and accidently removed. If this is the case, you should reinstall GNOME, GDM, and GNOME Software with dnf commands in a terminal window or using the command-line interface. You might also have to reinstall graphics drivers. You can use group to install the entire GNOME desktop. The group list command displays groups.

sudo dnf group install gnome-desktop
sudo dnf install gdm
sudo dnf install gnome-software

GNOME Software (Software)

GNOME Software is a desktop software management front end for DNF. The GNOME Software software manager is Internet based, installing from online repositories, using DNF to download and install. It is designed to be a cross-distribution package manager that can be used on any DNF supported Linux distribution.

GNOME Software performs a variety of different software tasks, including installation, removal, updating, and install of an individual RPM file. The GNOME Software application is gnome-software, accessible from the Applications overview as Software.

Figure 2-12: GNOME Software

GNOME Software is currently designed to install client and system applications.  It does not install server software, such as the DNS named server or the Apache Web server. It also does not install many of the older system configuration tools, such as system-config-samba or system-config-lvm. To manage such software you will have to install the older system-config-packages software manager, which goes by the name Packages on GNOME Software.

To use GNOME Software you click the Software icon on the Applications overview. GNOME Software will start up by gathering information on all your packages. A window opens with three tabs at the top for All, Installed, and Updates. You can install applications from the All tab, which displays a text box at the top for searching, a list of picks, featured applications, and a collection of category buttons (see Figure 2-12).

PackageKit  

PackageKit is an older software management front end for DNF. The PackageKit Package Manager (Packages) is Internet based, installing from online repositories, using DNF to download and install. It is designed to be a cross-distribution package manager that can be used on any DNF supported Linux distribution.

To use PackageKit you click the Packages icon on the Applications overview. PackageKit will start up by gathering information on all your packages. A Software window opens with a sidebar for searching and a category list (see Figure 2-13). Before you install packages, it is advisable to first refresh your software lists. This is the listings of software packages available on your enabled repositories. Select "Refresh Package Lists" from the PackageKit GNOME applications menu.

Figure 2-13: Software, PackageKit (Packages)

You can find packages by category by selecting a category on the sidebar. All the packages in that category are listed. Uninstalled packages have faded package icons with an empty checkbox, and installed packages have a solid color with a check mark in the checkbox. Categories let you browse through your software, seeing what is available for different kinds of tasks or features, like Multimedia applications or applications designed for the GNOME desktop.

To install a package, first, click its checkbox (see Figure 2-14). The box is checked and a plus sign appears on the package icon. You can click on several packages to select them for installation. Once you are ready to install, click the Apply Changes button (upper right). The status bar at the bottom will show tasks being performed, starting with downloading, then installing, and finally finished.

A progress bar will show the install task's progress. The PackageKit task messages are displayed in the top right corner. At the download phase, a Cancel button becomes active letting you cancel the install. Once installed, the package icon color will change from faded to a solid color and a checkmark displayed in its checkbox. If dependent or additional packages are required by the software you want to install, these are listed and you are prompted to confirm their installation. Click Continue. Each time you click Apply Changes to install packages, you are prompted to enter the root user password to authorize the installation.

Figure 2-14: Package information

Updating Fedora

New versions of Fedora are released every six months or so. In the meantime, new updates are continually being prepared for particular software packages. These are posted as updates you can download from software repositories and install on your system. These include new versions of applications, servers, and even the kernel. Such updates may range from single software packages to whole components.

Updating your Linux system has become a very simple procedure, using the automatic update tools. For Fedora, you can update your system by accessing software repositories supporting the DNF (Dandified YUM) update methods. DNF uses RPM headers to determine which packages need to be updated. From a command line, you can perform updates using the dnf upgrade command.

On the Fedora desktop, you can use either GNOME Software Updates tab to perform updates (the default), or you can use the older Software Update. Software Update is part of the PackageKit software manager and is installed with PackageKit. PackageKit is not installed by default. The name used for PackageKit on GNOME Software is simply Packages.

If updates are detected, GNOME Software will display an update message in the message tray (see Figure 2-15). Clicking on the notice opens GNOME Software to the Updates tab, from which you can then perform the update. Clicking on the Restart & Install button immediately shuts down your system, then restarts, and, as part of the startup process, downloads and installs updates.

Figure 2-15: Update notification message and icon

Update with the dnf command

To perform a complete update of all your installed packages, you use the dnf command with the upgrade option. This would have the same effect of updating with Software Update.

sudo dnf upgrade

You can use the check-update option to see what packages need to be updated.

dnf check-update

You can use the updateinfo option to see what packages need to be updated. With no option just a count of the kinds of updates is listed.  With the --list option, the packages to be updated are shown. For details about each update, use the --info option.

dnf updateinfo
dnf updateinfo --list
dnf updateinfo --info

You can also update just a single or set of packages. The following would update an already installed vsfptd package.

sudo dnf upgrade vsftpd

Automatic DNF Updates with dnf-automatic.

If you want updates performed automatically, you can install the dnf-automatic package. This package installs timers and services for three automatic update options: notifyonly, download, and install. The download option notifies and download only. The install option notifies, downloads, and installs. To designate an option, you enable and start its timer. The three timers are:

dnf-automatic-notifonly.timer
dnf-automatic-download.timer
dnf-automatic-install.timer

To choose the download and notify option, you would enter the following in a terminal window.

sudo systemctl enable dnf-automatic-download.timer
sudo systemctl start dnf-automatic-download.timer

To notify, download, and install, enable and start the install timer.

sudo systemctl start dnf-automatic-install.timer

To change from one option to another, be sure to disable the current one.

sudo systemctl disable dnf-automatic-install.timer
sudo systemctl enable dnf-automatic-notifyonly.timer
sudo systemctl start dnf-automatic-notifyonly.timer

Configuration for dnf-automatic is held in the /etc/dnf/automatic.conf file. The default entries for updates, download_updates and apply_updates, are overridden by the timer you have enabled. You can customize other entries such as those for email. Check the man page for dnf.automatic for configuration details.

Server Roles and rolekit

Server roles are designed to install and automatically configure dedicated servers. You can think of them as a much more complex form of packaging. Instead of installing then a combination of packages for a specific server and then configuring the server, you can install a server role to install all packages pre-configured. 

You manage roles using rolekit and the rolectl command. Install the rolekit package using Packages or with the dnf command (Fedora server already installs it). The rolekit man page provides a description. The rolekit package installs role configuration files for supported role servers in the /usr/lib/rolekit/roles directory. At present these include databaseserver (a PostgreSQL server), domain controller, and memcache. The /usr/lib/rolekit/roles directory has a subdirectory for each. Others will be added as they become available. You can also use rolekit to create roles.

Roles are managed using the rolectl command. The list roles options lists your available roles. Check the man page for rolectl for detailed descriptions of options.

$ rolectl list roles
databaseserver
domaincontroller
memcache

The current settings for a role can be listed using the settings option.

rolectl settings databaseserver

To list deployed roles (servers installed by rolekit) use the list instances option.

rolectl list instances

Use the deploy option to install a server.

sudo rolectl deploy databaseserver
Deployment can take a long time. To monitor the progress, run
journalctl -ef -u rolekit
success
sudo rolectl list instances
databaseserver/1

A server role has at least one instance. Some roles, such as the databaseserver role, allow multiple instances, whereas others, like the domaincontroller, allow only one. You could have several instances of the databaseserver role, each with a possibly different configuration. When you deploy an instance, it creates a corresponding systemd target file in the /etc/systemd/system. The .target file has the prefix "role-databaseserver." In this example, a databaseserver role instance named newserver is deployed, which creates a role-databaseserver-newserver.target file for it in the /etc/systemd/system/ directory. The target file connects to the postgresql.service file in the /lib/systemd/system directory.

role-databaseserver-newserver.target

[Unit]
Description=Database Server Role - newserver
Requires=postgresql.service
After=syslog.target
After=network.target
RequiredBy=postgresql.service
BindsTo=postgresql.service

[Install]
WantedBy=multi-user.target

If you deploy the domaincontroller role, its instance will also have a role target file in /etc/systemd/system. The target file will connect to the ipa.service file in /lib/systemd/system.

To start a server using a particular instance, you use the systemctl command and the instance's target file. Be sure to include the .target extension in the instance name.

systemctl start role-databaseserver-newserver.target

When deployed, a role configuration file for that instance is set up in the role's subdirectory in the /etc/rolekit/roles directory. The files use a JSON (JavaScript Object Notation) format and have the name of the instance with a .json extension, such as 1.json. JSON statements have a name/value structure.

You can edit the JSON configuration file to set user options for different server instances.  The databaseserver role supports user options for the database name, password, and owner.  domaincontroller role supports options for host and domain names, administration password, primary IP address, and DNS forwarder addresses, among others. Check the server role's man pages for details (rolekit.roles.domaincontroller and rolekit.roles.databaseserver).

You set the options when you deploy the role instance. Use the rolectl commands              --settings-file option to specify the json file in which you listed the options and their values. Specify the name of the option in quotes followed by a colon and the value you want to give to the option, also in quotes. The option list is encased in braces. The following show options for the databaseserver role listed in a file called myserver-options.json (the file can be any name, but requires a .json extension). You can create a json file using the gedit text editor and save the file with a .json extension.

myserver-options.json

   {
   "database": "myserver",
   "owner": "richard"
   }

To following installs an instance of a database server using the json file with user specified options.

rolectl deploy databaseserver --settings-file /home/richard/myserver-options.json

If no database option is assigned a value, the name of the database is automatically assigned the name of the instance. If no name is specified for the instance, the name of the database instance is set to the number of the instance, starting from 1, with a "db_" prefix. The /etc/rolekit/roles/databaseserver json file for a second instance would be named 2.json, and, if no database option is set, the database would be called db_2.

To specify a name of an instance, use the rolectl command's --name option. The json configuration file will then have that name, and, if not specified by a user setting, the database will also have that name. In the following example the configuration file is newserver.json and the database would be newserver.

rolectl deploy databaseserver --name newserver

User options take priority. In this example, the configuration file is newserver.json, but the database name is myserver. 

sudo rolectl deploy databaseserver --name newserver --settings-file /home/richard/myserver-options.json

You can remove an instance using the decommission role/instance option. Specify the role and the instance name, separated by a forward slash. Decommissioning will remove the configuration json file in the role's /etc/rolekit/roles/role directory. In the following example, the 1.json file in the /etc/rolekit/roles/databaseserver directory is removed.

sudo rolectl decommission database/1

Terminal Window

The Terminal window allows you to enter Linux commands on a command line. It also provides you with a shell interface for using shell commands instead of your desktop. The command line is editable, allowing you to use the backspace key to erase characters on the line. Pressing a key will insert that character. You can use the left and right arrow keys to move anywhere on the line, and then press keys to insert characters, or use backspace to delete characters (see Figure 2-16). Folders, files, and executable files are color coded: black for files, blue for folders, green for executable files, and aqua for links. Shared folders are displayed with a green background.

Figure 2-16: Terminal Window

The terminal window will remember the previous commands you entered. Use the up and down arrows to have those commands displayed in turn on the command line. Press the ENTER key to re-execute the currently displayed command. You can even edit a previous command before running it, allowing you to execute a modified version of a previous command. This can be helpful if you need to re-execute a complex command with a different argument, or if you mistyped a complex command and want to correct it without having to re-type the entire command. The terminal window will display all your previous interactions and commands for that session. Use the scrollbar to see any previous commands you ran and their displayed results.

You can open as many terminal windows as you want, each working in its own shell. Instead of opening a separate window for each new shell, you can open several shells in the same window, using tabs. Select Open Tab from the File menu to open a new tab (Shift-Ctrl-t). Each tab runs a separate shell, letting you enter different commands in each. You can use the Tabs menu to move to different tabs, or just click on its tab to select it. The Tab menu is displayed on the menu bar only if multiple tabs are open. For a single window, the Tab menu is not shown.

The terminal window also supports GNOME desktop cut/copy and paste operations. You can copy a line from a Web page and then paste it to the terminal window (you can use the Paste entry on the Terminal window's Edit menu or press Shift-Ctrl-v). The command will appear and then you can press ENTER to execute the command. This is useful for command line operations displayed on an instructional Web page. Instead of typing in a complex command yourself, just select and copy from the Web page directly, and then paste to the Terminal window. You can also perform any edits on the command if needed before executing it.

You can customize terminal windows using profiles. A default profile is set up already. To customize your terminal window, select Preferences from the Edit menu. This opens a window for setting your default profile options with option categories on the sidebar for Global and Profiles. In the Profiles section there will be an "Unnamed" profile, the default. Click on the down menu button to the right to open a menu with the options to copy the profile or change the name. To add another profile, click on the plus button to the right of the "Profiles" heading to open a dialog to create a new profile. For profiles you create you have the added options to delete them and or to set one as the default. A selected profile displays tabs for Text, Colors, Scrolling, Command, and Compatibility. On the Text tab, you can select the default size of a terminal window in text rows and columns.

Your terminal window will be set up to use a dark background with white text. To change this, you can edit the profile to change the background and text colors on the Colors tab.  De-select the "Use colors from system theme" entry. This enables the "Built-in schemes" menu from which you can select a "Black on white" display. Other color combinations are also listed, such as "Black on light yellow" and "Green on black." The Custom option lets you choose your own text and background colors. The colors on your open terminal window will change according to your selection, allowing you to see how the color choices will look. For a transparent background, choose the "Use transparent background" entry and then set the amount of shading (none is completely transparent and full shows no transparency).

The Scrolling tab specifies the number of command lines your terminal history will keep, as well as other scroll options such as the scroll speed and whether to display the scrollbar. These are the lines you can move back through and select to re-execute. You can de-select the Limit scrollback option to set this to unlimited to keep all the commands.

You can create new profiles with customized preferences. To create a new profile, choose New Profile from the File menu to open the New Profile window where you can enter the profile name and select any profile to base it on. The default profile is chosen initially. Use the Change Profile submenu on the Terminal menu to change profiles.

To edit a particular profile, select Preferences from the Edit menu to open the Preferences window, and then click on the one you want in the Profiles section.

Controlled Administrative Access: sudo and su

To perform system administration operations, you must be a user that has administrative access. You can then access administrative tools for specific tasks from any account, temporarily giving you superuser access for just that administrative operation. With administrative access, you can perform tasks such as starting up and shutting down the system, adding or removing users, formatting file systems, backing up and restoring files, and you may also specify the system’s hostname.

You use the sudo command to perform operations with administrative access. With the sudo tool, you can allow ordinary users to have limited root user–level administrative access for certain tasks. This allows other users to perform specific superuser operations without having full root level control. You can find more about sudo at https://www.sudo.ws. To use sudo to run a command, you precede the command with the sudo command. You will be prompted for your root password, which will grant access that remains in effect for several minutes.

sudo date
Password:

Unlike earlier Fedora releases, the sudo command is already configured for you and ready to use. It is considered the primary method for running commands with administrative access. You could still use the su command, though, if you want.

Note: The System Security Services daemon (SSSD) provides offline access for users relying on remote authentication, such as an LDAP server. The SSSD will cache the authentication method, allowing you to log in offline. Before SSSD, users had to maintain a corresponding local account from which to gain access when offline. SSSD is installed by default. You manage it with the sssd.service file. Configuration files are located at /etc/sssd. See https://fedoraproject.org/wiki/Features/SSSD for more details.

Running Desktop Applications with Administrative Access

On the Fedora Workstation (desktop), the Wayland display server does not allow root access to graphical tools, such as leafpad and gedit, as well as to some of the older administrative tools such as system-config-selinux. Many of these graphical administration tools were designed for the Xorg server and have not been updated for the Wayland server. A work around uses the xhost command to add an access control for the root user to the local user. In the terminal window, enter the following command to enable root access through the display server. You should only have to do this once each time you login.

xhost +si:localuser:root

You can then use leafpad, as shown here, to edit a system configuration file, in this case, /etc/default/grub.

sudo leafpad /etc/default/grub

One very common use is to employ the gedit or leafpad graphical text editors to edit system configuration files. There is no specific administrative tool to do this, so ordinarily, you would have to log in as the root user to perform this task. With the sudo command, however, you can edit any system configuration file from a normal account. The following example would let you edit the /etc/fstab file, used for automatic file system mounting. Open a terminal window and enter the command. You will be prompted for the user password, then gedit will start as a functional desktop editor.

sudo gedit /etc/fstab

You could even run the file manager as a sudo operation, allowing the file manager full administrative access from any normal account. The file manager will open to the root user account.

sudo nautilus

Logging In to the Root User Account Directly

There are situations in which you might want to log in directly to the root user account. If you are performing several administrative tasks at once, or if you have to modify configuration files directly, root user account access may work best. The root user is a special account reserved for system management operations with unrestricted access to all components of your Linux operating system. You can log in as the root user from a terminal window or from the command-line login prompt.

sudo su

When logged in as a user with administrative access on the desktop, you can then log in as a root user, using a terminal window and the sudo su command (su stands for switch user). This is helpful if you just need to run several commands as a root user. You can use the sudo su command with the root username, or the sudo su command alone (the root username will be assumed). You will be prompted to enter the root user password.

sudo su root
password:

In the following example, the user logs in as the root user and then runs the nmb script using the systemctl command, which requires root user access.

sudo su
password:
systemctl start nmb

To exit from a sudo su login operation, when you are finished with that account, simply enter exit.

exit

su

Alternatively, you can just enter the su command at the command line prompt, or, on the desktop, from a terminal window. An exit command returns you to your own user login. When you are logged in as the root, you can use su to log in as any user, without providing the password. In the next example, the user has logged in already. The su command then logs in as the root user, making the user a superuser.

$ pwd
/home/chris
$ su
password:
# cd
# pwd
/root
# exit
$

When logged in as the root user in a terminal window using the su command, you use and additional sudo command to run a GNOME desktop applications as the root user.  You cannot run the desktop applications directly as the root user. To run normal GNOME applications with root level access, you have to authenticate them individually. For example, the gedit GNOME editor can be run with administrative (root level) access using the sudo command as shown here.

sudo gedit

Editing is an issue because you may need to edit system configuration files that are accessible only as the root user. You can use the vi editor if you are familiar with its commands. But many users would prefer a desktop-like editor, such as gedit. You can also use a cursor-based editor like nano or leafpad to provide basic desktop-like editing for configuration files when logged in as the root user.

NoteThe su command can actually be used to log in to any user, provided you have that user’s password.

Root User Password

As the root user, you can use the passwd command to change the password for the root login, as well as for any other user on the system. The passwd command will check your password with Pluggable Authentication Modules (PAM), as discussed in Chapter 9, to see if you've selected one that can be easily cracked. To more easily change your root password from a GUI interface, you can use the system-config-rootpassword tool.

$ sudo passwd root
New password:
Re-enter new password:

You must take precautions to protect your root password. Anyone who gains access as the root user will have complete control over your system. The online manual for the passwd command provides detailed recommendations for handling and choosing your password. For example, never store your password in a file on your system, and never choose one based on any accessible information, such as your phone number or date of birth. A basic guideline is to make your password as complex as possible, using a phrase of several words with numbers and upper- and lowercase, yet something you can still remember easily so that you never have to write it down. You can access the passwd online manual page with the command

man passwd

sudo Configuration

For sudo, access is controlled by the /etc/sudoers file. This file lists users and the commands they can run, along with the password for access. If the NOPASSWD option is set, then users will not need a password. ALL, depending on the context, can refer to all hosts on your network, all root-level commands, or all users.

To make changes or add entries, you have to edit the file with the special sudo editing command visudo. This invokes the Vi editor to edit the /etc/sudoers file. Unlike a standard editor, visudo will lock the /etc/sudoers file and check the syntax of your entries. You are not allowed to save changes unless the syntax is correct. If you want to use a different editor, you can assign it to the EDITOR shell variable.

visudo

Entries in the sudoers file are technically referred to as specifications, of which there are two kinds: user and alias. The user specification is the primary entry that actually controls user access. The user specification has user, host, runas, and command lists. The user list is the users being controlled in this specification. The hosts are hosts the user can access. The runas list is the list of users the users can access the hosts as (a user with full root user capability should be able to access any user on a host). The command list is the list of commands those users can run. For any of these, you can use ALL to indicate all users (user list and runas), hosts, or commands.  The user specification has the following syntax:

users   hosts=(runas) commands

The (runas) segment is optional and is used to allow a user to access a host as another user. The runas segment is simply a list of users. Using ALL for the user gives access to all users.

The host is a host on your network. You can specify all hosts with the ALL term. The command can be a list of commands, some or all qualified by options such as whether a password is required. To specify all commands, you can also use the ALL term. The following gives the user george full root-level access to all commands on all hosts:

george  ALL = ALL

By default, sudo will deny access to all users but allows access by the root user. The default /etc/sudoers file sets full access for the root user to all commands using the ALL=(ALL) ALL entry.

root   ALL=(ALL)   ALL

To give a user full administrative access on all hosts (the same a root user access), you can copy the root user entry and replace root with the name of the user. The following gives full root user level access to the richard user.

richard  ALL=(ALL)   ALL

When editing the sudoers file with the visudo editor, to copy the line, move to the root line, then press the yy keys followed by the p key to copy and paste the line. Move to the root name in the copy and press the cw keys to edit the root name, and then type in the new name. Press the ESC key when finished, and then the ZZ keys to save and exit

You can also let a user run as another user on a given host. Such alternate users are placed within parentheses before the commands. For example, if you want to give george access to the beach host as the user mydns, you use the following:

george beach = (mydns) ALL

To let a user run as any user on all hosts, you would use ALL = (ALL), as is done for the root user.

george ALL=(ALL) ALL

To specify a group name, you prefix the group with a % sign, as in %mygroup. This way, you can give the same access to a group of users. The /etc/sudoers file contains samples for a %wheel group.

To give robert access on all hosts to the date command, you would use

robert ALL=/usr/bin/system-config-date

If a user wants to see what commands he or she can run, that user would use the sudo command with the -l option.

sudo -l

To better control access by different groups and users, sudo also supports alias specifications. See the sudo Man page for more details. You can set up aliases for users, hosts, and commands. Certain aliases are already set up for you. An alias has the following syntax:

alias-type   name    list

There are three types of aliases, one for each part of a sudo entry: User_Alias for users, Runas_Alias for users run as, Host_Alias for hosts, and Cmnd_Alias for commands. The Cmnd_Alias defines groups of commands that can then be easily referenced in a sudo definition. Several are already defined for you (though commented out) like for running file system operations like fdisk, parted, and mount.

Cmnd_Alias STORAGE = /sbin/fdisk, /sbin/parted /bin/mount

Certain User_Alias and Host_Alias entries are already defined in the /etc/sudoers file but commented out, like one for ADMINS. These are examples you can use to create an entry of your own.

# User_Alias ADMINS = jsmith, mkem

The following would allow the user robert to use the service and chkconfig commands on any host.

robert ALL=SERVICES

If the ADMINS user alias is defined, you could use the following to allow root level access to a group of users designated as administrators.

ADMINS  ALL=(ALL)  ALL

In addition, sudo also supports tags that provide specialized options. In particular, the NOPASSWD tag will allow a user to login without a password. The following would allow a user root level access without having to enter the root password.

george ALL = NOPASSWD: ALL

There are also options you can set for sudo, including authenticate to require a password, and passwd_timeout for the password prompt timeout. The rootpw option would require that users enter the root user password, instead of their own user password.

3. systemd: unit files and server management

A single Linux system can provide several different kinds of services, ranging from security to administration and including more obvious Internet services like web and FTP sites, e-mail, and printing. Security tools such as SSH and SSSD run as services, along with administrative network tools such as DHCP and LDAP. The network connection interface is itself a service that you can restart at will. Each service operates as a continually running daemon looking for requests for its particular services.

System startup is managed by the systemd service. The original System V init system for starting individual services has been phased out. The Upstart service used in previous Fedora releases has been deprecated.

systemd

Linux systems traditionally used the Unix System V init daemon to manage services by setting up runlevels at which they could be started or shutdown. Fedora has since replaced the SystemV init daemon with the systemd init daemon. Whereas the System V init daemon would start certain services when the entire system started up or shut down using shell scripts run in sequence, systemd uses sockets for all system tasks and services. systemd sets up sockets for daemons and coordinates between them as they start up. This allows systemd to start daemons at the same time (in parallel). Should one daemon require support from another, systemd coordinates the data from their sockets (buffering), so that one daemon receives the information from another daemon that it needs to continue. This parallel start up compatibility allows for very fast boot times.

In effect, you can think of systemd as a combination of System V init scripts and the inetd daemon (xinetd), using socket activation applied to all system startup tasks and to network servers. The socket activation design was originally inspired by the inetd service that used sockets (AT_INET) to start internet daemons when requested. The socket activation design was used by in Apple's OS X system to apply to all sockets (AF_UNIX). This allowed all start up processes to start at the same time in parallel, making for very fast boot times. Sockets are set up and managed by systemd. When D-BUS needs to write to journald (logging), it writes to the systemd-journald socket set up and managed by systemd. It does not have to communicate directly with journald. This means that services no longer have to be started and shutdown in a particular sequence as they were under System V. They can all start and stop at the same time. Also, as systemd controls the socket, if a service fails, its socket remains in place. The service can be restarted using the same socket with no loss of information. systemd manages all types of sockets including UNIX (system), INET (network), NETLINK (devices), FIFO (pipes), and POSIX (messages). See the following for more details:

https://docs.fedoraproject.org/quick-docs/en-US/understanding-and-administering-systemd.html
https://www.freedesktop.org/wiki/Software/systemd/

systemd sets up sockets for all system tasks and services. Configurations for systemd tasks are defined in unit files in /lib/systemd/system directory. In this respect, systemd files replace the entries that used to be in the Sys V init's /etc/inittab file. systemd also has its own versions of shutdown, reboot, halt, init, and telinit, each with their own man page. These versions are used on Fedora, instead of the original Linux versions.

systemd is entirely compatible with both System V scripts and /etc/fstab. The SystemV scripts and /etc/fstab are treated as additional configuration files for systemd to work with. If System V scripts are present it will use them to generated a corresponding unit configuration file, if there are no corresponding systemd unit configuration files already. systemd configuration always takes precedence. systemd will also, if needed, use the start and stop priority files in the System V init /etc/rc.d directory to determine dependencies.  Entries in /etc/fstab are used to generate corresponding systemd unit files that are then used to manage file systems.  systemd also supports snapshots that allow restoring services to a previous state.

systemd basic configuration files

You can configure systemd for system, login manager, users, and, journal service using the configuration files located in the /etc/systemd directory. When run for a system service, systemd uses the system.conf file, otherwise it uses the user.conf file. You can set options such as the log level (LogLevel) and resource size limits. See the man page for systemd.conf (system.conf and user.conf), logind.conf, and journald.conf for details on the options available.

units

systemd organizes tasks into units, each with a unit configuration file. There are several types of units (see Table 3-1). A unit file will have an extension to its name that specifies the type of unit it is. Service types have the extension .service, and mount types have the extension .mount. The service type performs much the same function as System V init scripts. Services can be stopped, started and restarted.  The systemctl command will list all units, including the ones it generates.

Units can also be used for socket, device, and mount tasks. The socket type implements the kind of connection used for inetd and xinetd, allowing you to start a service on demand. The device type references devices as detected by udev. The mount type manages a file system's mount point, and automount activates that mount point should it be automounted.  An automount unit file has a corresponding mount unit file, which it uses to mount a file system. Similarly, a socket type usually has a corresponding service type used to perform a task for that socket.

Within each unit are directives that control a service, socket, device, or mount point. Some directives are unique to the type of unit. These are listed in the man page for that service, such as systemd.service for the service unit, or systemd.mount for a mount unit (see Table 3-1). 

man systemd.service

Options common to units are listed in the systemd.exec and systemd.unit pages. The systemd.unit page lists directives common to all units such as Wants, Conflicts, Before, SourcePath, and Also. The systemd.exec pages list options for the execution of a program for a unit, such as the starting of a server daemon. These include options such as User, group, WorkingDirectory, Nice, Umask, and Environment. The systemd.exec page covers options for service, socket, mount, and swap units. The systemd.directives man page provides a listing of all systemd unit options and the man page for each option.

The target unit is used to group units. For example, targets are used to emulate runlevels.  A multi-user target groups units (services) together that, in System V, would run on runlevel 3. In effect, targets group those services that run on a certain runlevel for a certain task.  The printer target activates the CUPS service, and the graphical target emulates runlevel 5. A target can also be used to reference other targets. A default target designated the default runlevel.

Unit Type

Unit Man page

Description

service

systemd.service

Services such as servers, which can be started and stopped

socket

systemd.socket

Socket for services (allows for inetd like services, AF_INET)

device

systemd.device

Devices

mount

systemd.mount

File system mount points

automount

systemd.automount

Automount point for a file system. Use with mount units.

target

systemd.target

Group units

path

systemd.path

Manage directories

snapshot

systemd.snapshot

Created by systemd using the systemctl snapshot command to save runtime states of systemd. Use systemctl isolate to restore a state.

swap

systemd.swap

Swap unit file generated by systemd for the swap file system.

timer

systemd.timer

Time-based activation of a unit. Corresponds to a service file. Time formats are specified on the systemd.time man page.

systemd.unit

Man page with configuration options common to all units

systemd.exec

Man page for execution environment options for service, socket, mount, and swap units

systemd.special

Man page for systemd special targets such as multi-user.target and printer.target.

systemd.time

Time and date formats for systemd

systemd.directives

Listing of all systemd options and the man page they are described on.

Table 3-1: systemd unit types and man pages

Some unit files are automatically generated by systemd. For example, operations specified in the /etc/fstab are performed by mount units, which are automatically generated from the fstab entries.

Units can be dependent on one another, where one unit may require the activation of other units. This dependency is specified using directories with the .wants extension. For example, the poweroff.target is dependent on the console-kit-log-system-stop service and the plymouth-poweroff service. The directory poweroff.target.wants has symbolic links to these two services. Should you want a service dependent on your graphical desktop, you can add symbolic links to it in the graphical.target.wants directory.

It is important to distinguish between the wants directories in the /etc/systemd/system directory and those in the /lib/systemd/system directory. Those in the /lib/systemd directory are set up by your system and should be left alone. To manage your own dependencies, you can set up corresponding wants directories in the /etc/systemd/system directory. The /etc/systemd directory always takes priority. For example, in the /etc/systemd/system/multi-user.target.wants directory you can place links to services that you want started up for the multi-user.target (runlevel 3). Your system automatically installs links for services you enable, such as smb.service and httpd.service. These are all links to the actual service files in the /lib/systemd/system directory. The basic.target.wants directory holds a link to firewalld.service, starting up the firewall for all runlevels. The printer.target.wants directory has a link to the cups service.

  Disabling a service removes its link from its wants directory in /etc/systemd/system.  For example, disabling the httpd service removes its link from the /etc/systemd/system/multi-user.target.wants directory. The original service file, in this case, httpd.service, remains in the /lib/systemd/system directory. If you enable the service again, a link for it is added to the /etc/systemd/system/multi-user.target.wants directory.

The /etc/systemd/system directory also hold links to services.  The /etc/systemd/system/default.target file is a link to the /lib/systemd/system/multi-user.target.  The /etc/systemd/system/dbus-org.freedesktop.NetworkManager.service link references /lib/systemd/system/NetworkManager.service.

To manage systemd you can use systemctl or cockpit. 

unit file syntax

A unit file is organized into sections designated by keywords enclosed in brackets. All units have a unit section, [Unit], and an install section, [Install]. The options for these sections are descript in the systemd.unit Man page. Comments can be written by beginning a line with # or ; character. See Table 3-2 for a listing of commonly used Unit and Install section options.

The Unit section of a unit file holds generic information about a unit. The Description option provides information about the task the unit manages, such as the Samba server as shown here.

Description=Samba SMB Daemon

The Documentation option lists URIs for the application's documentation.

Documentation=man:dhcpd(8) man:dhcpd.conf(5)

Types of dependencies can be specified using the Before, After, Requires, Wants, and Conflicts options in the unit section. After and Before configure the ordering of a unit. In the following After option in the smb.service file, the smb service is started after system logging, networking, the nmbd server, and the Winbind server.

After=syslog.target network.target nmb.service winbind.service

The Requires option sets up a dependency between units. This is a strong dependency. If one fails so does the other. In the following Requires option from the graphical.target unit file, the graphical target can only be started if the multi-user target is activated.

After=multi-user.target

The Wants option sets up a weaker dependency, requiring activation, but not triggering failure should it occur. This is the case with the graphical target and the display manager service like GDM.

Wants=display-manager.service

Unit options

Description

[Unit]

Description

Description of the unit.

Documentation

URIs referencing documentation.

Requires

Units required by the service.  This is a strict requirement. If the required units fail, so will the unit.

Wants

Units wanted by the service.  This is not a strict requirement. If the required units fail, the unit will still start up.  Same functionality as the wants directories.

Conflicts

Negative unit dependency. Starting the unit stops the listed units in the Conflicts option. 

Before

Unit ordering.  Unit starts before the units listed.

After

Unit ordering.  Unit waits until the units listed start.

OnFailure

Units to be run if the unit fails.

SourcePath

File the configuration was generated from, such as the mount unit files generated from /etc/fstab.

[Install]

WantedBy

Sets up the unit's symbolic link in listed unit's .wants subdirectory. When the listed unit is activated, so is the unit. This is not a strict requirement.

RequiredBY

Sets up the unit's symbolic link in listed unit's .requires subdirectory. When the listed unit is activated, so is the unit. This is a strong requirement.

Alias

Additional names the unit is installed under. The aliases are implemented as symbolic links to the unit file.

Also

Additional units to install with this unit.

Table 3-2: systemd Unit and Install section options (common to all units, systemd.unit)

Several condition options are available such as ConditionACPower which, if true, checks to see if a system is using AC power. ConditionPathExists checks for the existence of file for static firewall rules. 

ConditionPathExists=/etc/sysconfig/iptables

Some unit files are automatically generated by systemd, allowing you to use older configuration methods. For example, the unit file used to manage the mounting of your file systems is generated from the configuration information in the /etc/fstab file. The SourcePath option specifies the configuration file used to generate the unit file. The SourcePath option for the boot.mount unit file is shown here.

SourcePath=/etc/fstab

The Install section provides installation information for the unit. The WantedBy and RequiredBy options specify units that this unit wants or requires. For service units managing servers like Samba and the Apache Web server, the install section has a WantedBy option for the multi-user.target. This has the effect of running the server at runlevels 2, 3, 4, and 5.  When the multi-user target becomes activated so does that unit.

WantedBy=multi-user.target

The WantedBy option is implemented by setting up a link to the unit in a wants subdirectory for the wanted by unit. For the multi-user.target unit, a subdirectory called multi-user.target.wants has symbolic links to all the units that want it, such as smb.service for the Samba service. These wants symbolic links are set up in the /etc/systemd/system directory, which can be changed as you enable and disable a service. Disabling a service removes the link. RequiredBy is a much stronger dependency.

The Alias option lists other unit names that could reference this unit. This is the case for the default.target, which is used to reference a startup target (runlevel). In the multi-user.target and the graphical.target files you will find an Alias option for default.target. When the system starts up, it activates a default target which is a symbolic link to the target you want.

Alias=default.target

The Also option lists other units that should be activated when this unit is started. The Sendmail service has an Also option to start the sendmail client service.

Also=sm-client.service

Different types of units have their own options. Service, socket, target, and path units all have options appropriate for their tasks. 

special targets

A target file groups units for services, mounts, sockets, and devices. systemd has a set of special target files designed for specific purposes (see Table 3-3). Some are used for on-demand services such as bluetooth and printer. When a bluetooth device is connected the bluetooth target becomes active. When you connect a printer, the printer target is activated which, in turn, activates the CUPS print server. The sound target is activated when the system starts and runs all sound-related units. See the special.target Man page for more details.  

There are several special target files that are designed to fulfill the function of runlevels in System V (see Table 3-4). These include the rescue, multi-user, and graphical targets. On boot, systemd activates the default target, which is a link to a special target, such as multi-user.target and graphical.target. You can override the default target with a systemd.unit kernel command line option in the GRUB.

The following will start up the rescue target.

systemd.unit=rescue.target

On the GRUB startup menu, you could edit the kernel boot line and add the following option to boot to the command line instead of the desktop.

systemd.unit=multi-user.target

The following will start up the rescue target.

systemd.unit=rescue.target

Special units

Description

basic.target

Units to be run at early boot

bluetooth.target

Starts when a Bluetooth device becomes active

printer.target

Starts printer service when a printer is attached.

sound.target

Starts when sound device is detected, usually at boot.

display-manager.service

Link to display services such as LightDM or KDM.

ctrl-alt-del.target

Activated when the user presses Ctrl-Alt-Del keys, this is a link to the reboot.target which reboots the system.

system-update.target

Implements an offline system update. After downloading, the updates are performed when your system reboots, at which time it detects the presence of the target.

Table 3-3: special units

On the GRUB startup menu, you could edit the kernel boot line and add the following option to boot to the command line instead of the desktop.

systemd.unit=multi-user.target

You could also simply add a 3 as in previous releases, as runlevel links also reference the special targets in systemd. The 3 would reference the runlevel 3 target, which links to the multi-user target.

Special Runlevel Targets

Description

default.target

References special target to be activated on boot

rescue.target

Starts up base system and rescue shell

emergency.target

Starts base system, with option to start full system

multi-user.target

Starts up command line interface, multi-user and non-graphical (similar to runlevel 3)

graphical.target

Start graphical interface (desktop) (similar to runlevel 5)

Table 3-4: special runlevel targets (boot)

A copy of the multi-user.target file follows. The multi-user target requires the basic target which loads the basic system (Requires). It conflicts with the rescue target (Conflicts), and it is run after the basic target. It can be isolated allowing you to switch special targets (AllowIsolate).  The default.target is an alias for it (Alias), letting that target start it.

multi-user.target

[Unit]
Description=Multi-User System
Documentation=man:systemd.special(7)
Requires=basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes

The graphical.target depends on the multi-user.target. A copy of the graphical.target unit file follows. It requires that the multi-user.target be activated (Requires). Anything run for the multi-user target, including servers, is also run for the graphical target, the desktop. The desktop target is run after the multi-user.target (After). It is not run for the rescue.target (Conflicts). It also wants the display-manager service to run (GDM or KDM) (Wants). You can isolate it to switch to another target (AllowIsolate).

graphical.target

[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts= rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes

Modifying unit files: /etc/systemd/system

systemd uses unit files to manage devices, mounts, and services. These are located in the /lib/systemd/system directory and are considered system files that you should not modify. You can modify a unit file either by specifying features that override those in the original, or by creating a separate copy that you can edit, which takes precedence over the original. In each case it is best to create the modifications using the systemctl command with the edit option.

Drop in files: .d directories

To simply override or add entries to the unit file, you can create an associated drop in directory that contains configuration files with entries. Such a directory has the same name as the unit file with a .d extension.  It contains configuration files with the extension .conf. For example, for the httpd.service file, there is a corresponding httpd.service.d directory, both in the /lib/systemd/system directory. Configuration files have a .conf extension, such as local.conf. The /lib/systemd/system/httpd.service.d/local.conf file will be read in by the /lib/systemd/system/httpd.service file and will take priority.  

To create a drop in directory and its configuration file, you simple edit the unit file with the systemctl edit command.

sudo systemctl edit vsftpd.service

This opens your default line editor and lets you add in the new entries. When you save, if the drop in directory does not exist, it is created. This creates an override.conf file in the /etc/systemd/system/vsftpd.service.d directory.

Note: Keep in mind that most runtime options for a service application, such as the Samba server, are still held in the appropriate /etc/sysconfig file, such as /etc/sysconfig/samba. This file is read by the service when it is activated. 

/etc/systemd/system

Should you want to make more extensive changes, you can create a copy of the original unit file in the /etc/systemd/system directory. Unit files in this directory take precedence over those in the /lib/systemd/system directory. You can then modify the unit file version in /etc/systemd/system. You would create this copy using the systemctl edit --full command.

sudo systemctl edit --full vsftpd.service

This opens your default line editor display the copy of the unit file, now in your /etc/systemd/system directory, and lets you modify or add entries.

Alternatively, you could copy a unit file to the /etc/systemd/system directory directly, and then edit it with a text editor. Use the cp command to copy the file. The following command copies the Samba service unit file.

sudo cp /lib/systemd/system/smb.service   /etc/systemd/system/smb.service

If you just want to add unit options to a unit file, not changing the original options in the /lib/systemd/system version, you do not have to copy the original unit file. Instead, you can set up a corresponding new unit file in /etc/systemd/system that has an include option that reads in the original unit file from /lib/systemd/system. Then, in the new /etc/systemd/system file, you can add the new

Note: The actual enabling or disabling of services such as Samba or vsftpd is handled through symbolic links set up or removed from the multi-user.target.wants directory in the /etc/systemd/system directory. This is considered a user based modification appropriate for /etc/systemd/system. 

Execution Environment Options

The unit files of type service, sockets, mount, and swap share the same options for the execution environment of the unit (see Table 3-5). These are found in the unit section for that type such as [Service] for service units or [Socket] for socket unit.  With these options, you can set features such as the working directory (WorkingDirectory), the file mode creation mask (UMask), and the system logging level (SysLogLevel). Nice sets the default scheduling priority level. User specifies the user id for the processes the unit runs.

User=mysql

service unit files

A service unit file is used to run applications and commands such as the Samba (smb) and Web (httpd) servers. They have a [Service] section with options specified in the systemd.service Man page. See Table 3-6 for a listing of several common service options. A service unit file has the extension .service and the prefix is the name of the server program, such as httpd.service for the Apache Web server and vsftpd.service for the Very Secure FTP server. Table 3-7 lists several popular servers.  

Exec options

Description

WorkingDirectory

Sets the working directory for an application.

RootDirectory

Root directory for an application

User, Group

Application's user and group ids.

Nice

Sets priority for an application

CPUSchedulingPriority

CPU Scheduling priority for the applications. 

UMask

File mode creation mask, default is 022.

Environment

Set environment variables for an application.

StandardOutput

Direct standard output a connection such as log, console, or null.

SysLogLevel

System logging level such as warn, alert, info, or debug.

DeviceAllow, DeviceDeny

Control applications access to a device.

ControlGroup

Assign application to a control group.

Table 3-5: systemd exec options (Service, Socket, Mount, Swap) (systemd.exec)

Service options

Description

ExecStart

Commands to execute when service starts, such as running an application or server.

Type

Startup type such as simple (the default), forking, dbus, notify, or idle

ExecStartPre, ExecStartPost

Commands executed before and after the ExecStart command.

TimeStartSec

Time to wait before starting the ExecStart command.

Restart

Restart when the ExecStart command end.  

PermissionsStartOnly

Boolean value, If true the permission based options are applied, such as User.  

RootDirectoryStartOnly

Boolean value, if true, the RootDirectory option applies only to the ExecStart option.

Table 3-6: systemd service options [Service] (systemd.service)

Service unit files

Description

cups

The CUPS printer daemon

dhcpd

Dynamic Host Configuration Protocol daemon

httpd

Apache Web server

iptables

Controls the IPtables daemon for static firewall

ip6tables

IPtables for IP protocol version 6 for static firewall

NetworkManager

Operations to start up or shut down your network connections.

nfs-server

Network Filesystem

postfix

Postfix mail server

sendmail

The Sendmail MTA daemon

smb

Samba for Windows hosts

squid

Squid proxy-cache server

sshd

Secure Shell daemon

systemd-journald

System logging daemon

vsftpd

Very Secure FTP server

ypbind

Network Information Service (NIS)

Table 3-7: Collection of Service unit files in /lib/systemd/system

A copy of the Samba service unit file, smb.service, follows. The Samba service is started after the system log, network, nmb, and Winbind services have started. It is of type forking (Type). An environment variable for Kerberos is defined (Environment). The process ID file is specified (PIDFile). A limit set to the number of files (LimitNOFILE). The configuration file for environment variables is located in the /etc/sysconfig directory, /etc/sysconfig/samba (EnvironmentFile). The server program to run is specified, /usr/sbin/smbd (ExecStart). The service is installed by the multi-user.target (WantedBy), in effect at runlevel 2, 3, 4, and 5, when the system starts up.

smb.service

[Unit]
Description=Samba SMB Daemon
Documentation=man:smbd(8) man:samba(7) man:smb.conf(5)
After=network.target nmbd.service winbind.service

[Service]
Type=notify
NotifyAccess=all
PIDFile=/run/smbd.pid
LimitNOFILE=16384
EnvironmentFile=-/etc/sysconfig/samba
ExecStart=/usr/sbin/smbd --foreground --no-process-group $SMBDOPTIONS
ExecReload=/bin/kill -HUP $MAINPID
LimitCORE=infinity
Environment=KRB5CCNAME=/run/samba/krb5cc_samba

[Install]
WantedBy=multi-user.target

A copy of the httpd.service unit file follows. It is run after network, remote file system mounts, and name service lookup. The service is of type notify (Type). It uses the /etc/sysconfig/httpd file for runtime environment options (EnvironmentFile). The server program run is /usr/sbin/httpd (ExecStart). The same program is used to reload and stop the server but with different options (ExecReload and ExecStop). It is started by the multi-user.target (WantedBy), which is the equivalent of runlevels 2, 3, 4, and 5.

httpd.service

[Unit]
Description=The Apache HTTP Server
Wants=httpd-init.service
After=network.target remote-fs.target nss-lookup.target httpd-init.service
Documentation=man:httpd.service(8)

[Service]
Type=notify
Environment=LANG=C

ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
# Send SIGWINNCH for graceful stop
KillSgnal=SIGWINCH
KillMode=mixed
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Some service files are very simple such as the hddtemp.service file for monitoring hard drive temperatures. It is run after the system log starts (After). An environment variable is set for the system to access, localhost (Environment). Its runtime environment options are in the /etc/sysconfig/hddtemp file. The program it starts is /usr/sbin/hddtemp (ExecStart). It is started by the multi-user.target when the system starts (WantedBy).

hddtemp.service

[Unit]
Description=Hard drive temperature monitor daemon
Documentation=man:hddtemp(8)

[Service]
Environment=HDDTEMP_OPTIONS=--listen=127.0.0.1
EnvironmentFile=-/etc/sysconfig/hddtemp
ExecStart=/usr/sbin/hddtemp -dF $HDDTEMP_OPTIONS

[Install]
WantedBy=multi-user.target

The dhcpd.service file is even simpler, incorporating configuration references into the program command. It is run after the network and time services and is started by the multi-user.target.

dhcpd.service

[Unit]
Description=DHCPv4 Server Daemon
Documentation=man:dhcpd(8) man:dhcpd.conf(5)
Wants-network-online.target
After=network-online.target
After=time-sync.target

[Service]
Type=notify
ExecStart=/usr/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid
StandardError=null

[Install]
WantedBy=multi-user.target

On Demand and Standalone Services (socket)

The On Demand activation of services, formerly implemented by inetd, is the default in systemd. Should you want a standalone service, you can specify that it is wanted by a special target so that it will be started up at boot time, instead of when it is first activated. In the Install section of a service unit file, a WantedBy option specifying the multi-user target will start the service at boot, making it a standalone service. In the following, the service is wanted by the multi-user.target. To put it another way, the service starts at runlevels 2, 3, 4, and 5. Note that the graphical target (5) is dependent on (Requires) the multi-user target (2, 3, and 4), so by specifying the multi-user target, the service is also started with the graphical target.

[Install]
WantedBy=multi-user.target

The Bluetooth service only wants the bluetooth.target which is only activated if a Bluetooth device is present. It is not started at boot.

[Install]
WantedBy=bluetooth.target

Should you want the service started at all runlevels, you would use the basic.target, as is done for iptables (iptables.service).

[Install]
WantedBy=basic.target

To emulate an on-demand server service, as inetd used to do, you would use a .socket file to compliment a .service file. This is the case with CUPS, which has a cups service file and corresponding cups socket file. The WantedBy option for sockets.target ties the socket to the special target sockets.target, which makes the unit socket-activated.

The Socket section lists options for the socket, usually what socket to listen on (ListenStream). The systemd.socket Man page lists socket options. Table 3-8 lists common options. 

Socket options

Description

ListenStream

Address to listen on for a stream. The address can be a port number, path name for a socket device, or an IPv4 or IPv6 address with a port number. 

Accept

If true, service instance is set up for each connection; if false, only one service instance is set up for all connections

MaxConnections

Maximum number of connections for a service

Service

Service unit to run when the socket is active. Default is a service name that is the same as the socket name. 

Table 3-8: systemd socket file options [Socket] (systemd.socket)

cups.socket

[Unit]
Description=CUPS Scheduler

[Socket]
ListenStream=/var/run/cups/cups.sock

[Install]
WantedBy=sockets.target

cups.service

[Unit]
Description=CUPS Scheduler
Documentation=man:cupsd(8)
After=network.target

[Service]
ExecStart=/usr/sbin/cupsd -l
Type=notify

[Install]
Also=cups.socket cups.path
WantedBy=printer.target

Path units

systemd uses path units to monitor a path. Sometimes a service unit has a corresponding path unit to monitor directories, as is the case with cups.path and cups.service. Options for the Path section are listed in Table 3-9 and on the systemd.path Man page. The cups.path unit file is shown here. The PathExistsGlob option checks if the printer spool files exist.

cups.path

[Unit]
Description=CUPS Scheduler

[Path]
PathExistsGlob=/var/spool/cups/d*

[Install]
WantedBy=multi-user.target

path options

Description

PathExists

Activates if a file exists

PathExistsGlob

Activates if there exists a file matching a pattern, such as any file in a specified directory.

PathModified

Activates if a file has been modified

Table 3-9: path option (systemd.path)

Template unit files

There is a special type of unit file called a template file, which allow for the generation of several unit files at runtime using one template file. Templates are used for services that generate instances of a service such as a getty terminal, an OpenVPN connection, and an rsync connection. A template file name ends with an @ sign.  If a corresponding unit file is not found for a service, systemd will check to see if there is a template file that can be applied to it. systemd matches the service name with the template name. It then generates an instance unit for that particular service.

For example, a terminal uses the getty service (get TTY). As you do not know how many terminals you may use, they are generated automatically using the getty@.service unit file.

In the configuration file, the %I specifier is used to substitute for the service name. Given the service name getty@tty3, the %I specifier substitutes for tty3. The uppercase %I uses the argument literally, making no changes in the filename (the literal name).

ExecStart=-/sbin/agetty --noclear %I $TERM

The getty@.service template file is shown here.

getty@.service

[Unit]
Description=Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
After=systemd-user-sessions.service plymouth-quit-wait.service getty-pre.target
After=rc-local.service

# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes

# IgnoreOnIsolate causes issues with sulogin, if someone isolates
# rescue.target or starts rescue.service from multi-user.target or
# graphical.target.
Conflicts=rescue.service
Before=rescue.service

# On systems without virtual consoles, don't start any getty. Note
# that serial gettys are covered by serial-getty@.service, not this
# unit.
ConditionPathExists=/dev/tty0

[Service]
# the VT is cleared by TTYVTDisallocate
# The '-o' option value tells agetty to replace 'login' arguments with an
# option to preserve environment (-p), followed by '--' for safety, and then
# the entered username.
ExecStart=-/sbin/agetty -o '-p -- \\u' --noclear %I $TERM
Type=idle
Restart=always
RestartSec=0
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes

# Unset locale for the console getty since the console has problems
# displaying some internationalized messages.
UnsetEnvironment=LANG LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION

[Install]
WantedBy=getty.target
DefaultInstance=tty1

The lowercase %i specifier escapes characters in the argument to make sure the file name is valid. The OpenVPN client service uses the uppercase %I for the description and a lowercase %i for execution.

openvpn-client@.service

[Unit]
Description=OpenVPN tunnel for %I
After=syslog.target network-online.target
Wants=network-online.target
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
Type=notify
PrivateTmp=true
WorkingDirectory=/etc/openvpn/client
ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE
LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw
ProtectSystem=true
ProtectHome=true
KillMode=process

[Install]
WantedBy=multi-user.target

Runlevels and Special Targets

Under the old System V, a Linux system could run in different levels, called runlevels, depending on the capabilities you want to give it. Under System V, Linux had several runlevels, numbered from 0 to 6. When you power up your system, you enter the default runlevel. Runlevels 0, 1, and 6 are special runlevels that perform specific functions. Runlevel 0 was the power-down state. Runlevel 6 was the reboot state—it shuts down the system and reboots. Runlevel 1 was the single-user state, which allowed access only to the superuser and does not run any network services.

systemd uses special targets instead of runlevels create the same effect as runlevels, grouping services to run for specified targets. Runlevels are no longer directly implemented. There are two major special targets: multi-user and graphical. The multi-user target is similar to runlevel 3, providing you with a command line login. The graphical target is similar to runlevel 5, providing you with a graphical login and interface.

You set the default target (runlevel) by linking a target's systemd service file to the systemd default target file. This operation replaces the way inittab was used to specify a default runlevel in previous releases. The inittab file is no longer used. The following makes the graphical interface the default (runlevel 5).

ln -s /lib/systemd/system/graphical.target  /etc/systemd/system/default.target

systemd does provide compatibility support for runlevels. Runlevel compatibility is implemented using symbolic links in /lib/system/systemd directory to systemd targets.  The runlevel0.target link references the systemd poweroff.target.  Runlevel 2, 3, and 4 targets all link to the same multi-user.target (command line interface).  The runlevel6.target links to the reboot target, and runlevel5.target links to graphical.target (desktop interface). The runlevels and their targets are listed in Table 3-10.

You can still use the runlevel command to see what state you are currently running in. It lists the previous state followed by the current one. If you have not changed states, the previous state will be listed as N, indicating no previous state. This is the case for the state you boot up in. In the next example, the system is running in state 3, with no previous state change:

# runlevel
N 3

System Runlevel links

systemd targets

runlevel0

poweroff.target

runlevel1

rescue.target

runlevel2

multi-user.target

runlevel3

multi-user.target

runlevel4

multi-user.target.

runlevel5

graphical.target.

runlevel6

reboot.target

Table 3-10: System Runlevels (States)

Changing runlevels can be helpful if you have problems at a particular runlevel. For example, if your video card is not installed properly, then any attempt to start up in runlevel 5 (graphical.target) will likely fail, as this level immediately starts your graphical interface. Instead, you should use the command line interface, runlevel 3 (multi-user.target), to fix your video card installation.

No matter what runlevel you start in, you can change from one runlevel to another with the telinit command. If your default runlevel is 3, you power up in runlevel 3, but you can change to, say, runlevel 5 with telinit 5. The command telinit 0 shuts down your system. In the next example, the telinit command changes to runlevel 1, the administrative state:

telinit 1

Before systemd was implemented, you could also use init to also change runlevels. With systemd, both telinit and init are now systemd emulation versions of the original UNIX commands. The telinit command is always used to change runlevels. If you use init with a runlevel number, it now merely invokes telinit to make the change.

Alternatively, you can use the systemctl command directly to change runlevels (targets). The systemctl command with the isolate option and the name of the target file changes to that target (runlevel). The following command changes to the multi-user target.

systemctl isolate multi-user.target

You could also use the runlevel link instead.

systemctl isolate runlevel3.target

This is what the telinit command actually does.

systemd and automatically mounting file systems: /etc/fstab

The systemd unit files with the extension .mount can be used to mount file systems automatically. Normally systemd will read the /etc/fstab for mount information.  If a mount unit file exists in the /etc/systemd directory, it takes precedence, but /etc/fstab takes precedence over any unit mount files in the /lib/systemd directory. Currently, on Fedora, the /etc/fstab file is used for mount configuration information. Most of the options for a mount unit file correspond to those of the /etc/fstab file, specifying the device path name, the mount point, file system type, and mount options (see Table 3-11). In fact, the entries in the /etc/fstab file are converted to mount unit files at boot, which are then used by systemd to perform the actual mount operations.  These mount unit files are created by the systemd-fstab-generator and can be found in the /run/systemd/generator directory. 

The following fstab file entries have corresponding mount files created in the /run/systemd/generator directory: boot.mount for the boot file system, home.mount for the home file system, and  -.mount for the fedora root file system. For the swap file system a swap unit file is generated, dev-mapper-fedora\x2dswap.swap.  For Fedora Server "-server" is added to the /dev/mapper names, as in fedora--server-home or fedora-server-root. For the fedora-home and fedora-root partitions, the Fedora Workstation uses ext2 formatting, and Fedora Server uses xfs.

/dev/mapper/fedora-root /        xfs    defaults   1 1
UUID=e759aa59-4a86-4072-982e-000717229b4a /boot    ext4   defaults   1 2
UUID=F075-3DA4 /boot/efi    vfat   umask=0077,shortname=winnt 0 2
/dev/mapper/fedora-home /home    xfs    defaults   1 2
/dev/mapper/fedora-swap swap     swap    defaults   0 0

For this example, the -.mount file used for the root file system will have the following mount options.  The root directory is represented in the mount file name as a dash, -, instead of a slash, /. The mount options are listed in a [Mount] section. The Fedora Workstation uses ext2 formatting, and Fedora Server uses xfs.

[Mount]
Where=/
What=/dev/mapper/fedora-root
Type=xfs

The home.mount file references /dev/mapper/fedora-home file system and mounts it to the /home directory. The Fedora Workstation uses ext2 formatting, and Fedora Server uses xfs.

[Mount]
Where=/home
What=/dev/mapper/fedora-home
Type=xfs

The boot.mount file mounts the ext4 file system that holds the kernel in the /boot directory. 

[Mount]
Where=/boot
What=/dev/disk/by-uuid/e759aa59-4a86-4072-982e-000717229b4a
Type=ext4

The EFI partition (required by UEFI motherboards) uses a vfat partition, boot-efi.mount.

[Mount]
Where=/boot/efi
What=/dev/disk/by-uuid/F075-3DA4
Type=vfat
options=umask=0077,shortname=winnt

mount options

Description

What

Path of the device

Where

Directory of the mount point.

Type

File system type

Options

Mount options

DirectoryMode

Permissions for created file system mount directories

TimeoutSec

Time to wait for a mount operation to finish

automount options

Description

Where

Mount point for the file system. If it does not exist, it will be created.

DirectoryMode

Permissions for any directories created.

Table 3-11: systemd mount and automount file options [Mount] [Automount]

All the unit files will designate the /etc/fstab file as the SourcePath, the file from which the configuration was generated from.

SourcePath=/etc/fstab

All are mounted before any local file systems.

Before=local-fs.target

Local and remote file systems are distinguished by Wants options in their unit files for local-fs.target or remote-fs.target. 

A mount unit file has to be named for the mount point it references. The path name slashes are replaced by dashes in the unit name. For example, the proc-fs-nfsd.mount file references the mount point /proc/fs/nfsd.  The root path name, /, becomes simple a dash, -.

For file systems to be automatically mounted when accessed you can use the automount unit type.  An automount unit must have a corresponding mount unit of the same name.

systemd slice and scope units

The slice and scope units are designed to group units to more easily control their processes and resources.  The scope units are generated by systemd to manage a process and its subprocesses. An example of a scope unit is a user session scope that groups the processes for a user session together. A slice is used to manage resources for processes, such as the machine slice for virtual machines, the system slice for system services, and the user slice for usr sessions. 

System V: /etc/rc.d/init.d

The SysVinit support for services is no longer implemented. There are no rc.d scripts for starting services. systemd manages all services directly. Check the README file in the /etc/init directory. For a very few system tasks, you may find System V scripts in the /etc/rc.d/init.d directory.  systemd will read these scripts as configuration information for a service, generating a corresponding unit configuration file for it. Should there be a unit file already in existence, that unit file is used and the System V script is ignored. An rc-local.service unit file in the /lib/systemd/system directory will run a /etc/rc.d/rc.local file, if present. This is to maintain compatibility with older System V configuration.

Shutdown and Poweroff

You can use the shutdown and poweroff commands to power down the system. The shutdown command provides more options. Keep in mind that the shutdown command used is the systemd version, which will use poweroff.target to actually shut down the system. The poweroff command with the -f option forces a shutdown, with the --reboot option, it reboots the system.

poweroff

The shutdown command has a time argument that gives users on the system a warning before you power down. You can specify an exact time to shut down, or a period of minutes from the current time. The exact time is specified by hh:mm for the hour and minutes. The period of time is indicated by a + and the number of minutes.

The shutdown command takes several options with which you can specify how you want your system shut down. The -h option, which stands for halt, simply shuts down the system, whereas the -r option shuts down the system and then reboots it. In the next example, the system is shut down after ten minutes:

shutdown -h +10

To shut down the system immediately, you can use +0 or the word now. The shutdown options are listed in Table 3-12. The following example shuts down the system immediately and then reboots:

shutdown -r now

With the shutdown command, you can include a warning message to be sent to all users currently logged in, giving them time to finish what they are doing before you shut them down.

shutdown -h +5 "System needs a rest"

If you do not specify either the -h or the -r options, the shutdown command shuts down the multi-user mode and shifts you to an administrative single-user mode. In effect, your system state changes from 3 (multi-user state) to 1 (administrative single-user state). Only the root user is active, allowing the root user to perform any necessary system administrative operations with which other users might interfere.

Command

Description

shutdown
[-rkhncft] time[warning]

Shuts the system down after the specified time period, issuing warnings to users; you can specify a warning message of your own after the time argument; if neither -h nor -r is specified to shut down the system, the system sets to the administrative mode, runlevel state 1.

Argument

Time

Has two possible formats: it can be an absolute time in the format hh:mm, with hh as the hour (one or two digits) and mm as the minute (in two digits); it can also be in the format +m, with m as the number of minutes to wait; the word now is an alias for +0.

Option

-t sec

Tells init to wait sec seconds between sending processes the warning and the kill signals, before changing to another runlevel.

-k

Doesn't actually shut down; only sends the warning messages to everybody.

-r

Reboots after shutdown, runlevel state 6.

-h

Halts after shutdown, runlevel state 0.

-n

Doesn’t call init to do the shutdown; you do it yourself.

-f

Skips file system checking (fsck) on reboot.

-c

Cancels an already running shutdown; no time argument.

Table 3-12: System Shutdown Options

Note: the halt command now merely halts the system, it does not turn it off.

Managing Services

You can select certain services to run and the special target (runlevel) at which to run them. Most services are servers like a Web server or FTP server. Other services provide security, such as SSH or Kerberos. You can decide which services to use with the systemctl or cockpit tools.

Enabling services: starting a service automatically at boot

Most services are servers like a Web server or proxy server. Other services provide security, such as SSH, Kerberos, and SSSD. Services such as the Apache Web server, Samba server, and the FTP server are now handled by the systemd daemon. You can decide which services to start when the system boots using the systemctl command.

To have a service start up at boot, you need to first enable it using the systemctl tool as the root user. Use the enable command to enable the service. The following command enables the vsftpd server and the Samba server (smb). The systemctl command uses the service's service configuration file located in the /lib/systemd/system directory. You will need administrative access with the sudo or su commands.

sudo systemctl enable vsftpd.service
sudo systemctl enable smb

Managing services manually

Use the start, stop, and restart command with systemctl to manually start, stop, and restart a service.  The enable command only starts up a service automatically.  You could choose to start it manually when you wish using the start command.  You can stop and restart a service any time using the stop and restart commands. The condrestart command only starts the server if it is already stopped. Use the status command to check the current status of service. Actions, such as start and stop, require administrative access with the sudo command. Reports such as status, do not.

sudo systemctl start vsftpd
sudo systemctl restart vsftpd
sudo systemctl condrestart vsftpd
sudo systemctl stop vsftpd
systemctl status vsftpd

You can also use cockpit to start, stop, or restart a service. It is a front end for the systemctl command which performs the actual operation using systemd.

sudo systemctl start vsftpd

Cockpit

The Cockpit management console (under development by Red Hat) provides a Web interface for managing both system administration and internet servers on your system, as well as servers on your network (https://cockpit-project.org). The Web interface works best on a desktop system (Fedora workstation). You can use it to manage your system resources, including services, storage, and networking. Once you install cockpit, be sure to enable it with systemd, and then allows access by your firewall for both cockpit and https. The package name is cockpit.

sudo dnf install cockpit
sudo systemctl start cockpit
sudo firewall-cmd --permanent --add-service=cockpit

Figure 3-1: Services, cockpit

You can access cockpit using a Web browser and accessing port 9090 on your local system. If you install on the workstation, a Cockpit icon is displayed on the applications overview that you can click to open cockpit with your default browser. The cockpit page initially prompts you for your username and password. It then shows a listing of the systems on your network. Upon clicking one, you will see links on the left side for administration categories such as System administration, services, networking, and storage. Click on the services link to manage your services. Then click the System Services tab to list the enabled and disabled service, including the network services such as the Apache Web server and the vsftpd FTP server (see Figure 3-1). Click on a service to open a page where you can manage service. Buttons to the right show the current status. Clicking on an arrow button to the right displays a menu for actions you may want to take, such as stopping or restarting a service. If you disable a service, it is moved down to the disabled list. Enabling a service moves it up to the enabled list.

Cockpit dynamically updates with systemctl. Should you make changes in a terminal window using systemctl, the changes are immediately shown on Cockpit. 

The service Command

The service command is now simply a front end for the systemctl command which performs the actual operation using systemd. The service command cannot enable or disable services. It only performs management operations such as stop, restart, and status. To start and stop services manually, you can user either systemctl, cockpit, or the service command. With the service command, you enter the service name with the stop argument to stop it, the start argument to start it, and the restart argument to restart it. The service command is run from a Terminal window. You will have to first log in as the root user, using the sudo or su commands. The following will start the smb Samba service.

sudo service start smb

In Fedora, the systemd version of the service command actually invokes the systemctl command to run the service's systemd .service unit file in /lib/systemd/system. You can perform the same operations as the service command, using the systemctl command. The following is the equivalent of the previous command.

sudo systemctl start smb

Extended Internet Services Daemon (xinetd)

Xinetd functionality is now performed by systemd. Only a few older applications still make use of it. The xinetd package is not installed by default. You should install it only if an older package requires it. Use chkconfig to turn a xinetd service on. The service is started up or shut down, and the disable line in its xinetd configuration script in the /etc/xinetd.d directory is edited accordingly.

4. Firewalls

Most systems currently connected to the Internet are open to attempts by outside users to gain unauthorized access. Outside users can try to gain access directly by setting up an illegal connection, by intercepting valid communications from users remotely connected to the system, or by pretending to be a valid user. Firewalls, encryption, and authentication procedures are ways of protecting against such attacks. A firewall prevents any direct unauthorized attempts at access, encryption protects transmissions from authorized remote users, and authentication verifies that a user requesting access has the right to do so. The current Linux kernel incorporates support for firewalls using the Netfilter (IPtables) packet filtering package (the previous version, IP Chains, is used on older kernel versions). To implement a firewall, you provide a series of rules to govern what kind of access you want to allow on your system. If that system is also a gateway for a private network, the system’s firewall capability can effectively help protect the network from outside attacks.

You can run your firewall on a stand-alone system directly connected to the Internet, or on a gateway system that connects a local network to the Internet. Most networks now use dedicated routers for Internet access which have their own firewalls. If instead, you decide to use a Linux system as a gateway, it will have at least two network connections, one for the local network and an Internet connection device for the Internet. Make sure that the firewall is applied to the Internet device, not to your local network.

Web Site

Security Application

https://netfilter.org/

Netfilter project, Iptables, and NAT

https://netfilter.org/ipchains

IP Chains firewall

www.openssh.org

Secure Shell encryption

https://fedoraproject.org/wiki/FirewallD

FirewallD

www.squid-cache.org

Squid Web Proxy server

https://web.mit.edu/Kerberos

Kerberos network authentication

Table 4-1: Network Security Applications

To provide protection for remote communications, transmission can be simply encrypted. For Linux systems, you can use the Secure Shell (SSH) suite of programs to encrypt any transmissions, preventing them from being read by anyone else. Kerberos authentication provides another level of security whereby individual services can be protected, allowing the use of a service only to users who are cleared for access. Outside users may also try to gain unauthorized access through any Internet services you may be hosting, such as a Web site. In such a case, you can set up a proxy to protect your site from attack. For Linux systems, use Squid proxy software to set up a proxy to protect your Web server (see Chapter 14). Table 4-1 lists several network security applications commonly used on Linux.

For clarity, the examples in this chapter use the traditional network device name (like eth0 and eth1) instead of the predictable device names (like enp7s0). Keep in mind, that, unless you rename your network devices (see Chapter 2), the actual devices on your system will use a predictable device name (like enp7s0).

Dynamic and Static Firewalls: FirewallD and the iptables command

Traditionally firewalls were static. You modified firewall rules and then restarted your firewall to load the rules. Fedora has adopted a dynamic firewall, called FirewallD, which can apply modified rules without restarting the firewall. Rules, however, have to be managed directly by the FirewallD daemon. You cannot use the iptables command to add firewall rules for the firewalld daemon. In fact, FirewallD does not use netfilter rules in the traditional sense. You do not list a set of rules that the firewall then reads, as you do with static firewalls like iptables. Instead, you use to firewall-config and firewall-cmd tools to directly configure your firewall.

FirewallD is managed by systemd using the firewalld.service unit file, /lib/systemd/system/firewalld.service. It is started before networking (Before) and conflicts with the static iptables managed firewall (Conflicts). Runtime configuration is read from /etc/sysconfig/firewalld (EnvironmentFile). Communication with the FirewallD daemon is handled over Dbus. FirewallD is started by the basic target (WantedBy), which means it starts for all start-up targets.

firewalld.service

[Unit]
Description=firewalld - dynamic firewall daemon
Before=network-pre.target
Wants=network-pre.target
After=dbus.service
After=polkit.service
Conflicts=iptables.service ip6tables.service ebtables.service ipset.service
Documentation=man:firewalld(1)

[Service]
EnvironmentFile=-/etc/sysconfig/firewalld
ExecStart=/usr/sbin/firewalld --nofork $FIREWALLD_ARGS
ExecReload=/bin/kill -HUP $MAINPID
# supress to log debug and error output also to /var/log/messages
StandardOutput=null
StandardError=null
Type=dbus
BusName=org.fedoraproject.FirewallD1
KillMode=mixed

[Install]
WantedBy=basic.target
Alias=dbus-org.fedoraproject.FirewallD1.service

If you wish, you can still use iptables instead of FirewallD to manage firewalls. Older customized firewall configurations may still want to use the older iptables static firewall. IPtables systemd unit files manage static IPtables rules, much like System V scripts did in previous releases. The iptables command keeps firewall rules in /etc/sysconfig/iptables, which is checked for (ConditionPathExists).  The iptables operation runs an iptables.init script to start and stop the firewall. The script reads runtime configuration from /etc/sysconfig/iptables-config. 

iptables.service

[Unit]
Description=IPv4 firewall with iptables
After=syslog.target
ConditionPathExists=/etc/sysconfig/iptables
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/libexec/iptables/iptables.init start
ExecStop=/usr/libexec/iptables/iptables.init stop
Environment=BOOTUP=serial
Environment=CONSOLETYPE=serial
StandardOutput=syslog
StandardError=syslog
[Install]
WantedBy=basic.target

Dynamic Firewall with FirewallD

FirewallD is the default firewall used in Fedora and runs as a daemon implementing a dynamic firewall.  Instead of loading rules offline from a file, you add them directly to the FirewallD daemon. For documentation see:

https://fedoraproject.org/wiki/FirewallD

FirewallD sets up network zones to define the level of trust for different kinds of network connections (see Table 4-2). Each zone can have several connections, but a connection can belong only to one zone. FirewallD defines several zones, most of which you can change (mutable). The drop and block zones are immutable and designed to stop all incoming packets. The public, external, and dmz zones are designed for untrusted networks, exposing only part of your system.  The work, home, and internal zone are used for trusted networks. The trusted zone (also immutable) allows all network connections.  

Zone configurations are located in /etc/firewalld/zones. You can use firewall-config or firewall-cmd to manage your zones and add new ones. The default zone is set in the /etc/firewalld.conf configuration files by the DefaultZone variable. Initially, it is set to public. The default and fallback zones are saved in /lib/firewalld/zones. 

Zone files are saved as XML files which list the zone name and the services and ports allowed. Also any masquerade, ICMP, and port forwarding options. 

firewall-config

Fedora uses the Firewalld firewall daemon.  To configure Firewalld you use the firewall-config graphical interface. You can also use firewall-cmd command from the command line. To set up your firewall, run firewall-config (Sundry | Firewall) (see Figure 4-1). The firewall is configured using zones displayed on the Zones tab. To configure a particular service you use the Services tab. Additional tabs can be displayed from the View menu for configuring ICMP types, whitelists, and for adding firewall rules directly (Direct Configuration).

Zone

Description

drop (immutable)

Deny all incoming connections, outgoing ones are accepted.

block (immutable)

Deny all incoming connections, with ICMP host prohibited messages issued.

trusted (immutable)

Allow all network connections

public

Public areas, do not trust other computers

external

For computers with masquerading enabled, protecting a local network

dmz

For computers publicly accessible with restricted access. 

work

For trusted work areas

home

For trusted home network connections

internal

For internal network, restrict incoming connections

Table 4-2: FirewallD zones

Figure 4-1: firewall-config: Runtime Configuration

With firewall-config, you can configure either a Runtime Configuration or Permanent Configuration. Select one from the Configuration. The Runtime Configuration shows your current runtime set up, whereas a Permanent configuration does not take effect until you reload or restart. If you wish to edit your zones and services you need to choose the Permanent Configuration (see Figure 4-2). This view displays a zone toolbar for editing zone at the bottom of the zone scroll box, and an Edit Services button for editing service protocols, ports, and destination addresses. 

Figure 4-2: firewall-config: Permanent Configuration

A firewall configuration is set up for a given zone, such as a home, work, internal, external, or public zone. . Zones provide an added level of protection by the firewall. They divide the network protected by the Firewall into separate segments, which can only communicate as permitted by the firewall. In effect, zones separate one part of your network from another. Each zone has its own configuration. Each zone has its own configuration. Zones are listed in the Zone scroll box on the left side of the firewall-config window (see Figure 4-3). Select the one you want to configure. The firewall-config window opens to the default, which can be FedoraWorkstation or FedoraServer, depending on the version installed. You can choose the default zone from the System Default Zone dialog (see Figure 4-4), which you open from the Options menu as "Change Default Zone."

Figure 4-3: Default Zone

If you choose Permanent Configuration from the Configuration Menu, a toolbar for zones is displayed below the Zone scroll box, as shown here. The plus button lets you add a zone, minus removes a zone. The pencil/page button lets you edit a zone. The add and edit buttons open the Base Zone Settings dialog, where you enter or edit the zone name, version, description, and the target (see Figure 4-4). The default target is ACCEPT. Other options are REJECT and DROP. The Load Zone Defaults button (yellow arrow) loads default settings, removing any you have made.

Figure 4-4: Base Zone Settings

Each zone, in turn, can have one or more network connections. From the Options menu choose "Change Zones of Connections" to open the Network Connections dialog where you can add a network connection.

Figure 4-5: Service Settings

For a given zone you can configure services, ports, masquerading, port forwarding, interfaces, rich rules, sources, and ICMP filter (see Figure 4-5). The feature many users may want to change are the services. A Linux system is often used to run servers for a network. If you are creating a strong firewall but still want to run a service such as a Web server, an FTP server, Samba desktop browsing, or SSH encrypted connections, you must specify them in the Services tab. Samba desktop browsing lets you access your Samba shares, like remote Windows file systems, from your GNOME or KDE desktops.

For a selected service, you can specify service settings such as ports and protocols it uses, any modules, and specific network addresses. Default settings are already set up for you such as port 139 for Samba, using the TCP protocol. To modify the settings for service, click the Services tab on the Firewall Configuration window to list your services. Choose the service you want to edit from the Service scroll box at the left.  For a given service you can then use the Ports and Protocols, Modules, and Destination tabs to specify ports, protocols, modules, and addresses. On the Ports and Protocols tab click the Add button to open the Port and/or Protocol dialog where you can add a port or port range, and choose a protocol from the Protocol menu (see Figure 4-6). On the Destination tab, you can enter an IPv4 or IPv6 destination address for the service. 

Figure 4-6: Service Protocols and Ports

The Ports tab lets you specify ports that you may want opened for certain services, like BitTorrent. Click the Add button to open a dialog where you can select the port number along with the protocol to control (tcp or udp), or enter a specific port number or range.

If your system is being used as a gateway to the Internet for your local network, you can implement masquerading to hide your local hosts from outside access from the Internet. This, though, also requires IP forwarding which is automatically enabled when you choose masquerading. Local hosts will still be able to access the Internet, but they will masquerade as your gateway system. You would select for masquerading the interface that is connected to the Internet. Masquerading is available only for IPv4 networks, not IPv6 networks.

The Port Forwarding tab lets you set up port forwarding, channeling transmissions from one port to another, or to a different port on another system. Click the Add button to add a port, specifying its protocol and destination (see Figure 4-7).

Figure 4-7: Port Forwarding

The ICMP Filters tab allows you to block ICMP messages. By default, all ICMP messages are allowed. Blocking ICMP messages makes for a more secure system. Certain types of ICMP messages are often blocked as they can be used to infiltrate or overload a system, such as the ping and pong ICMP messages (see Figure 4-8).

Figure 4-8: ICMP Filters

If you have specific firewall rules to add, use the Direct Configuration tab (displayed from the View | Direct Configuration menu).

firewall-cmd

The firewall-cmd command works on a command line interface, using options to set features for different zones.  Zone modification options such as --add-service, can be either runtime or permanent. Runtime changes are gone after a restart or reload. To make the changes permanent you add the --permanent option, making changes for a permanent configuration, instead of a runtime one. Be sure to use the sudo command for operations that make changes to your firewall configuration.

Use the get options to display information about the firewall.  The --get-zones option lists your zones, the --get-services option list services supported by the current zone, and the --get-icmptypes lists the ICMP types. 

firewall-cmd --get-zones
firewall-cmd --get-services
firewall-cmd --get-icmptypes

The --get-default-zone option lists the default zone, and --set-default-zone sets up a new default zone.

sudo firewall-cmd --set-default-zone  home

To find out what features have been enabled for a zone, use the --list-all option with a --zone= option to specify the zone.

firewall-cmd --zone=home  --list-all

Zone are assigned network interfaces. There are interface options to add, remove, or change an interface.  Use the query option to check if an interface belongs to a zone.

firewall-cmd --zone=home  --query-interface=enp7s0

The service, port, masquerade, icmp, and forwarding options can be either runtime or permanent. The --service options can add and remove services to a zone.

sudo firewall-cmd -add-service=vsftp

To make the change permanent, add the --permanent option.

sudo firewall-cmd --permanent -add-service=vsftp

The --query-service option checks to see if a service is enabled for a zone.

firewall-cmd --zone=home --query-service=http

The --port options are used to add, remove, or query ports.

sudo firewall-cmd --zone=home --add-port=22

Add the --permanent option to make it permanent.

sudo firewall-cmd --permanent --zone=home --add-port=22

The --masquerade option add, removes, and queries zones for masquerading.

sudo firewall-cmd --zone=work --add-masquerade

The --icmp-block options add, remove, and query ICMP types.

sudo firewall-cmd --zone=work --add-icmp-block=echo-reply

Should your firewall needs to use custom firewall rules, you can add, remove, and list them using the --direct option. These are rules written in the IPtables syntax.  You have to specify the protocol, table, chain, and arguments. The following lists the rules you added to the netfilter table. The rules are not saved and have to be added again each time you restart or reload.  You could have a script of firewall-cmd rules to do this.

firewall-cmd --direct --get-rules ipv4 netfilter

The following adds a simple netfilter rule.

sudo firewall-cmd --direct -add-rule ipv4 netfilter INPUT  Deny

Firewall Rules: Netfilter, NAT, mangle

A good foundation for your network’s security is to set up a Linux system to operate as a firewall for your network, protecting it from unauthorized access. You can use a firewall to implement either packet filtering or proxies. Packet filtering is simply the process of deciding whether a packet received by the firewall host should be passed on into the local network. The packet-filtering software checks the source and destination addresses of the packet and sends the packet on, if it’s allowed. Even if your system is not part of a network but connects directly to the Internet, you can still use the firewall feature to control access to your system. Of course, this also provides you with much more security.

An additional task performed by firewalls is network address translation (NAT). Network address translation redirects packets to appropriate destinations. It performs tasks such as redirecting packets to certain hosts, forwarding packets to other networks, and changing the host source of packets to implement IP masquerading.

Firewalls also can perform packet mangling, which modifies packet information to control operations like routing, connection size, and priority.

The Netfilter software package implements packet filtering, NAT tasks, and packet mangling for the Linux 2.4 kernel and above. The Netfilter software is developed by the Netfilter Project, which you can find out more about at https://netfilter.org.

Both FirewallD and the iptables command set up firewall rules.  FirewallD introduces an added level of abstraction, having you use the firewall-config and firewall-cmd tool to set up your firewall.  You do not write any actual firewall rules. This level of abstraction allows for a dynamic firewall implementation, generating rules at runtime. For the iptables command, you have to write actual firewall rules, which are loaded before the firewall starts (static firewall). As the iptables command lets you see exactly how the commands are set up, it is used in these examples to show how netfilter, mangle, and NAT table are set up. 

Modules

Unlike its predecessor, IP Chains, Netfilter is designed to be modularized and extensible. Capabilities can be added in the form of modules such as the state module, which adds connection tracking. Required modules are loaded as part of the IPtables service. Others are optional; you can elect to load them before installing rules. The required IPtables modules are located at /lib/modules/kernel-version/kernel/net/ipv4/netfilter, where kernel-version is your kernel number. For IPv6 modules, check the ipv6/netfilter directory. Iptables modules have an ipt_ prefix and Nat table modules have a nf_nat prefix. 

The optional IPtables modules, also known as helper modules, are located in the /lib/modules/kernel-version/kernel/net/netfilter directory. Modules that apply to the netfilter table begin with the prefix nf, and those that apply to all tables begin with the prefix xt. An example of a helper module is a connection tracking module that tracks packets that belong to an established connection, like an FTP download connection tracker module. The conntrack helper modules have the name conntrack, such as nf_conntrack_ftp.ko. 

For iptables static firewalls, helper modules are specified as a list assigned to the IPTABLES_MODULES variable located in the /etc/sysconfig/iptables-config file, which is used by the iptables service script. In this example, the IPTABLES_MODULES variable is assigned the ftp and netbios helpers.

IPTABLES_MODUELS="nf_conntrack_ftp  nf_conntrack_netbios_ns"

Whenever you start IPtables with the iptables script, they will be automatically loaded. For IPv6 configuration, you use the ip6tables-config file.

sudo systemctl restart iptables

If you are writing you own iptables script, instead of using the Red Hat or Fedora service iptables script, you would have to add modprobe commands to load optional modules directly.

You can create your own IPtables modules which you can have loaded. These modules should use the newer Xtables prefix xt.

Packet Filtering

Netfilter is essentially a framework for packet management that can check packets for particular network protocols and notify parts of the kernel listening for them. Built on the Netfilter framework is the packet selection system implemented by IPtables. With IPtables, different tables of rules can be set up to select packets according to differing criteria. Netfilter currently supports three tables: filter, nat, and mangle. Packet filtering is implemented using a filter table that holds rules for dropping or accepting packets. Network address translation operations such as IP masquerading are implemented using the NAT table that holds IP masquerading rules. The mangle table is used for specialized packet changes. Changes can be made to packets before they are sent out when they are received, or as they are being forwarded. This structure is extensible in that new modules can define their own tables with their own rules. It also greatly improves efficiency. Instead of all packets checking one large table, they access only the table of rules they need to.

IP table rules are managed using the iptables command. For this command, you will need to specify the table you want to manage. The default is the filter table, which need not be specified. You can list the rules you have added at any time with the -L and -n options, as shown here. The -n option says to use only numeric output for both IP addresses and ports, avoiding a DNS lookup for hostnames. You could, however, just use the -L option to see the port labels and hostnames:

iptables -L -n

Chains

Rules are combined into different chains. The kernel uses chains to manage packets it receives and sends out. A chain is simply a checklist of rules. These rules specify what action to take for packets containing certain headers. The rules operate with an if-then-else structure. If a packet does not match the first rule, the next rule is then checked, and so on. If the packet does not match any rules, the kernel consults chain policy. Usually, at this point, the packet is rejected. If the packet does match a rule, it is passed to its target, which determines what to do with the packet. The standard targets are listed in Table 4-3. If a packet does not match any of the rules, it is passed to the chain’s default target.

Target

Function

ACCEPT

Allow packet to pass through the firewall.

DROP

Deny access by the packet.

REJECT

Deny access and notify the sender.

QUEUE

Send packets to user space.

RETURN

Jump to the end of the chain and let the default target process it.

Table 4-3: IPtables Targets

Targets

A target could, in turn, be another chain of rules, even a chain of user-defined rules. A packet could be passed through several chains before finally reaching a target. In the case of user-defined chains, the default target is always the next rule in the chains from which it was called. This sets up a procedure–like the flow of control found in programming languages. When a rule has a user-defined chain as its target, when activated, that user-defined chain is executed. If no rules are matched, execution returns to the next rule in the originating chain.

Firewall and NAT Chains

The kernel uses three firewall chains: INPUT, OUTPUT, and FORWARD. When a packet is received through an interface, the INPUT chain is used to determine what to do with it. The kernel then uses its routing information to decide where to send it. If the kernel sends the packet to another host, the FORWARD chain is checked. Before the packet is actually sent, the OUTPUT chain is also checked. In addition, two NAT table chains, POSTROUTING and PREROUTING, are implemented to handle masquerading and packet address modifications. The built-in Netfilter chains are listed in Table 4-4.

Chain

Description

INPUT

Rules for incoming packets

OUTPUT

Rules for outgoing packets

FORWARD

Rules for forwarded packets

PREROUTING

Rules for redirecting or modifying incoming packets, NAT table only

POSTROUTING

Rules for redirecting or modifying outgoing packets, NAT table only

Table 4-4: Netfilter Built-in Chains

Adding and Changing Rules

You add and modify chain rules using the iptables commands. An iptables command consists of the command iptables, followed by an argument denoting the command to execute. For example, iptables -A is the command to add a new rule, whereas iptables -D is the command to delete a rule. The iptables commands are listed in Table 4-5. The following command simply lists the chains along with their rules currently defined for your system. The output shows the default values created by iptables commands.

iptables -L -n
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):

Option

Function

-A chain

Appends a rule to a chain.

-D chain [ rulenum]

Deletes matching rules from a chain. Deletes rule rulenum (1 = first) from chain.

-I chain [rulenum]

Inserts in chain as rulenum (default 1 = first).

-R chain rulenum

Replaces rule rulenum (1 = first) in chain.

-L [chain]

Lists the rules in chain or all chains.

-E [chain]

Renames a chain.

-F [chain]

Deletes (flushes) all rules in chain or all chains.

-R chain

Replaces a rule; rules are numbered from 1.

-Z [chain]

Zero counters in chain or all chains.

-N chain

Creates a new user-defined chain.

-X chain

Deletes a user-defined chain.

-P chain target

Changes policy on chain to target.

Table 4-5: IPtables Commands

To add a new rule to a chain, you use -A. Use -D to remove it, and -R to replace it. Following the command, list the chain to which the rule applies, such as the INPUT, OUTPUT, or FORWARD chain, or a user-defined chain. Next, you list different options that specify the actions you want taken (most are the same as those used for IP Chains, with a few exceptions). The -s option specifies the source address attached to the packet, -d specifies the destination address, and the -j option specifies the target of the rule. The ACCEPT target will allow a packet to pass. The -i option now indicates the input device and can be used only with the INPUT and FORWARD chains. The -o option indicates the output device and can be used only for OUTPUT and FORWARD chains. Table 4-6 lists several basic options.

\

Option

Function

-p [!] proto

Specifies a protocol, such as TCP, UDP, ICMP, or ALL.

-s [!] address[/mask] [!] [port[:port]]

Source address to match. With the port argument, you can specify the port.

--sport [!] [port[:port]]

Source port specification. You can specify a range of ports using the colon, port:port.

-d [!] address[/mask] [!] [port[:port]]

Destination address to match. With the port argument, you can specify the port.

--dport [!][port[:port]]

Destination port specification.

--icmp-type [!] typename

Specifies ICMP type.

-i [!] name[+]

Specifies an input network interface using its name (for example, eth0). The + symbol functions as a wildcard. The + attached to the end of the name matches all interfaces with that prefix (eth+ matches all Ethernet interfaces). Can be used only with the INPUT chain.

-j target [port]

Specifies the target for a rule (specify [port] for REDIRECT target).

--to-source < ipaddr> [-< ipaddr>][: port- port]

Used with the SNAT target, rewrites packets with new source IP address.

--to-destination < ipaddr> [-< ipaddr>][: port- port]

Used with the DNAT target, rewrites packets with new destination IP address.

-n

Numeric output of addresses and ports, used with -L.

-o [!] name[+]

Specifies an output network interface using its name (for example, eth0). Can be used only with FORWARD and OUTPUT chains.

-t table

Specifies a table to use, as in -t nat for the NAT table.

-v

Verbose mode, shows rule details, used with -L.

-x

Expands numbers (displays exact values), used with -L.

[!] -f

Matches second through last fragments of a fragmented packet.

[!] -V

Prints package version.

!

Negates an option or address.

-m

Specifies a module to use, such as state.

--state

Specifies options for the state module such as NEW, INVALID, RELATED, and ESTABLISHED. Used to detect packet’s state. NEW references SYN packets (new connections).

--syn

SYN packets, new connections.

--tcp-flags

TCP flags: SYN, ACK, FIN, RST, URG, PS, and ALL for all flags.

--limit

Option for the limit module (-m limit). Used to control the rate of matches, matching a given number of times per second.

--limit-burst

Option for the limit module (-m limit). Specifies maximum burst before the limit kicks in. Used to control denial-of-service attacks.

Table 4-6: IPtables Options

IPtables Options

The IPtables package is designed to be extensible, and there are a number of options with selection criteria that can be included with IPtables. For example, the TCP extension includes the --syn option that checks for SYN packets. The ICMP extension provides the --icmp-type option for specifying ICMP packets as those used in ping operations. The limit extension includes the --limit option, with which you can limit the maximum number of matching packets in a specified time period, such as a second.

Note: In IPtables commands, chain names have to be entered in uppercase, as with the chain names INPUT, OUTPUT, and FORWARD.

In the following example, the user adds a rule to the INPUT chain to accept all packets originating from the address 192.168.0.55. Any packets that are received (INPUT) whose source address (-s) matches 192.168.0.55 are accepted and passed through (-j ACCEPT):

iptables -A INPUT -s 192.168.0.55 -j ACCEPT

Accepting and Denying Packets: DROP and ACCEPT

There are two built-in targets, DROP and ACCEPT. Other targets can be either user-defined chains or extensions added on, such as REJECT. Two special targets are used to manage chains, RETURN and QUEUE. RETURN indicates the end of a chain and returns to the chain it started from. QUEUE is used to send packets to user space.

iptables -A INPUT -s www.myjunk.com -j DROP

You can turn a rule into its inverse with an ! symbol. For example, to accept all incoming packets except those from a specific address, place an ! symbol before the -s option and that address. The following example will accept all packets except those from the IP address 192.168.0.45:

iptables -A INPUT -j ACCEPT ! -s 192.168.0.45

You can specify an individual address using its domain name or its IP number. For a range of addresses, you can use the IP number of their network and the network IP mask. The IP mask can be an IP number or simply the number of bits making up the mask. For example, all of the addresses in network 192.168.0 can be represented by 192.168.0.0/225.255.255.0 or by 192.168.0.0/24. To specify any address, you can use all or simply 0/0. By default, rules reference any address if no -s or -d specification exists. The following example accepts messages coming in that are from (source) any host in the 192.168.0.0 network and that are going (destination) anywhere at all (the -d option is left out or could be written as -d 0/0):

iptables -A INPUT -s 192.168.0.0/24  -j ACCEPT

The IPtables rules are usually applied to a specific network interface such as the Ethernet interface used to connect to the Internet. For a single system connected to the Internet, you will have two interfaces, one that is your Internet connection and a loopback interface (lo) for internal connections between users on your system. The network interface for the Internet is referenced using the device name for the interface. For example, an Ethernet card with the device name eth0 would be referenced by the name eth0. A modem using PPP protocols with the device name ppp0 would have the name ppp0. In IPtables rules, you use the -i option to indicate the input device; it can be used only with the INPUT and FORWARD chains. The -o option indicates the output device and can be used only for OUTPUT and FORWARD chains. Rules can then be applied to packets arriving and leaving on particular network devices. In the following examples, the first rule references the Ethernet device eth0, and the second references the localhost:

iptables -A INPUT -j DROP -i eth0 -s 192.168.0.45
iptables -A INPUT -j ACCEPT  -i lo

User-Defined Chains

With IPtables, the FORWARD and INPUT chains are evaluated separately. One does not feed into the other. This means that if you want to completely block certain addresses from passing through your system, you will need to add both a FORWARD rule and an INPUT rule for them.

iptables -A INPUT -j DROP -i eth0 -s 192.168.0.45
iptables -A FORWARD -j DROP -i eth0 -s 192.168.0.45

A common method for reducing repeated INPUT and FORWARD rules is to create a user chain that both the INPUT and FORWARD chains feed into. You define a user chain with the -N option. The next example shows the basic format for this arrangement. A new chain is created called incoming (it can be any name you choose). The rules you would define for your FORWARD and INPUT chains are now defined for the incoming chain. The INPUT and FORWARD chains then use the incoming chain as a target, jumping directly to it and using its rules to process any packets they receive.

iptables -N incoming

iptables -A incoming -j DROP -i eth0 -s 192.168.0.45
iptables -A incoming -j ACCEPT  -i lo

iptables -A FORWARD -j incoming
iptables -A INPUT -j incoming

ICMP Packets

Firewalls often block certain Internet Control Message Protocol (ICMP) messages. ICMP redirect messages, in particular, can take control of your routing tasks. You need to enable some ICMP messages, however, such as those needed for ping, traceroute, and particularly destination-unreachable operations. In most cases, you always need to make sure destination-unreachable packets are allowed; otherwise, domain name queries could hang. Some of the more common ICMP packet types are listed in Table 4-7. With the --icmp-type option you can enable an ICMP type of packet, which takes as its argument a number or a name representing the message. The following examples enable the use of echo-reply, echo-request, and destination-unreachable messages, which have the numbers 0, 8, and 3:

iptables -A INPUT -j ACCEPT  -p icmp -i eth0 --icmp -type  echo-reply -d 10.0.0.1
iptables -A INPUT -j ACCEPT  -p icmp -i eth0 --icmp-type  echo-request -d 10.0.0.1
iptables -A INPUT -j ACCEPT -p icmp -i eth0 --icmp-type destination-unreachable -d 10.0.0.1

Their rule listing will look like this:

ACCEPT     icmp --  0.0.0.0/0            10.0.0.1           icmp type 0
ACCEPT     icmp --  0.0.0.0/0            10.0.0.1           icmp type 8
ACCEPT     icmp --  0.0.0.0/0            10.0.0.1           icmp type 3

Number

Name

Required By

0

echo-reply

ping

3

destination-unreachable

Any TCP/UDP traffic

5

redirect

Routing if not running routing daemon

8

echo-request

ping

11

time-exceeded

traceroute

Table 4-7: Common ICMP Packets

Ping operations need to be further controlled to avoid the ping-of-death security threat. You can do this several ways. One way is to deny any ping fragments. Ping packets are normally very small. You can block ping-of-death attacks by denying any ICMP packet that is a fragment. Use the -f option to indicate fragments.

iptables -A INPUT -p icmp -j DROP -f

Another way is to limit the number of matches received for ping packets. You use the limit module to control the number of matches on the ICMP ping operation. Use -m limit to use the limit module, and --limit to specify the number of allowed matches. 1/s will allow one match per second.

iptables -A FORWARD -p icmp --icmp-type echo-request -m limit -- 1/s -j ACCEPT

Controlling Port Access

If your system is hosting an Internet service, such as a Web or FTP server, you can use IPtables to control access to it. You can specify a particular service by using the source port (--sport) or destination port (--dport) options with the port that the service uses. IPtables lets you use names for ports such as www for the Web server port. The names of services and the ports they use are listed in the /etc/services file, which maps ports to particular services. For a domain name server, the port would be domain. You can also use the port number if you want, preceding the number with a colon. The following example accepts all messages to the Web server located at 192.168.0.43:

iptables -A INPUT -d 192.168.0.43 --dport www -j ACCEPT

Common ports checked and their labels are shown here:

Service

Port Number

Port Label

Auth

113

auth

Finger

79

finger

FTP

21

ftp

NTP

123

ntp

Portmapper

111

sunrpc

Telnet

23

telnet

Web server

80

www

You can also use port references to protect certain services and deny others. This approach is often used if you are designing a firewall that is much more open to the Internet, letting users make freer use of Internet connections. Certain services you know can be harmful, such as Telnet and NTP, can be denied selectively. For example, to deny any kind of Telnet operation on your firewall, you can drop all packets coming in on the Telnet port, 23. To protect NFS operations, you can deny access to the port used for the portmapper, 111. You can use either the port number or the port name.

# deny outside access to portmapper port on firewall.
iptables -A arriving  -j DROP -p tcp -i eth0  --dport 111
# deny outside access to telnet port on firewall.
iptables -A arriving  -j DROP -p tcp -i eth0  --dport telnet

The rule listing will look like this:

DROP      tcp  --  0.0.0.0/0    0.0.0.0/0     tcp dpt:111
DROP      tcp  --  0.0.0.0/0    0.0.0.0/0     tcp dpt:23

One port-related security problem is access to your X server ports that range from 6000 to 6009. On a relatively open firewall, these ports could be used to illegally access your system through your X server. A range of ports can be specified with a colon, as in 6000:6009. You can also use x11 for the first port, x11:6009. Sessions on the X server can be secured by using SSH, which normally accesses the X server on port 6010.

iptables -A arriving  -j DROP -p tcp -i eth0  --dport 6000:6009

Packet States: Connection Tracking

One of the more useful extensions is the state extension, which can easily detect tracking information for a packet. Connection tracking maintains information about a connection such as its source, destination, and port. It provides an effective means for determining which packets belong to an established or related connection. To use connection tracking, you specify the state module first with -m state. Then you can use the --state option. Here you can specify any of the following states:

State

Description

NEW

A packet that creates a new connection

ESTABLISHED

A packet that belongs to an existing connection

RELATED

A packet that is related to, but not part of, an existing connection, such as an ICMP error or a packet establishing an FTP data connection

INVALID

A packet that could not be identified for some reason

RELATED+REPLY

A packet that is related to an established connection, but not part of one directly

If you are designing a firewall that is meant to protect your local network from any attempts to penetrate it from an outside network, you may want to restrict packets coming in. Simply denying access by all packets is unfeasible because users connected to outside servers—say, on the Internet—must receive information from them. You can, instead, deny access by a particular kind of packet used to initiate a connection. The idea is that an attacker must initiate a connection from the outside. The headers of these kinds of packets have their SYN bit set on and their FIN and ACK bits empty. The state module’s NEW state matches on any such SYN packet. By specifying a DROP target for such packets, you deny access by any packet that is part of an attempt to make a connection with your system. Anyone trying to connect to your system from the outside is unable to do so. Users on your local system who have initiated connections with outside hosts can still communicate with them. The following example will drop any packets trying to create a new connection on the eth0 interface, though they will be accepted on any other interface:

iptables -A INPUT -m state --state NEW -i eth0 -j DROP

You can use the ! operator on the eth0 device combined with an ACCEPT target to compose a rule that will accept any new packets except those on the eth0 device. If the eth0 device is the only one that connects to the Internet, this still effectively blocks outside access. At the same time, input operations for other devices such as your localhost are free to make new connections. This kind of conditional INPUT rule is used to allow access overall with exceptions. It usually assumes that a later rule such as a chain policy will drop remaining packets.

iptables -A INPUT -m state --state NEW ! -i eth0 -j ACCEPT

The next example will accept any packets that are part of an established connection or related to such a connection on the eth0 interface:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Tip: You can use the iptstate tool to display the current state table.

Specialized Connection Tracking: ftp, irc, Amanda, tftp.

To track certain kinds of packets, IPtables uses specialized connection tracking modules. These are optional modules that you have to have loaded manually. To track passive FTP connections, you would have to load the ip_conntrack_ftp module. To add NAT table support, you would also load the ip_nat_ftp module. For IRC connections, you use ip_conntrack_irc and ip_nat_irc. There are corresponding modules for Amanda (the backup server) and TFTP (Trivial FTP).

If you are writing your own iptables script, you would have to add modprobe commands to load the modules.

modprobe ip_conntrack ip_conntrack_ftp ip_nat_ftp
modprobe ip_conntrack_amanda ip_nat_amanda

Network Address Translation (NAT)

Network address translation (NAT) is the process whereby a system will change the destination or source of packets as they pass through the system. A packet will traverse several linked systems on a network before it reaches its final destination. Normally, they will simply pass the packet on. However, if one of these systems performs a NAT on a packet, it can change the source or destination. A packet sent to a particular destination could have its destination address changed. To make this work, the system also needs to remember such changes so that the source and destination for any reply packets are altered back to the original addresses of the packet being replied to.

NAT is often used to provide access to systems that may be connected to the Internet through only one IP address. Such is the case with networking features such as IP masquerading, support for multiple servers, and transparent proxying. With IP masquerading, NAT operations will change the destination and source of a packet moving through a firewall/gateway linking the Internet to computers on a local network. The gateway has a single IP address that the other local computers can use through NAT operations. If you have multiple servers but only one IP address, you can use NAT operations to send packets to the alternate servers. You can also use NAT operations to have your IP address reference a particular server application such as a Web server (transparent proxy). NAT tables are not implemented for ip6tables.

Note: Using proxies, you can control access to specific services, such as web or FTP servers. You need a proxy for each service you want to control. The web server has its own web proxy, while an FTP server has an FTP proxy. Proxies can also be used to cache commonly used data, such as Web pages, so that users needn’t constantly access the originating site. The proxy software commonly used on Linux systems is Squid.

Adding NAT Rules

Packet selection rules for NAT operations are added to the NAT table managed by the iptables command. To add rules to the NAT table, you have to specify the NAT table with the -t option. Thus to add a rule to the NAT table, you would have to specify the NAT table with the -t nat option as shown here:

iptables -t nat

With the -L option, you can list the rules you have added to the NAT table:

iptables -t nat -L -n

Adding the -n option will list IP addresses and ports in numeric form. This will speed up the listing, as iptables will not attempt to do a DNS lookup to determine the hostname for the IP address.

Nat Targets and Chains

In addition, there are two types of NAT operations: source NAT, specified as SNAT target, and destination NAT, specified as DNAT target. SNAT target is used for rules that alter source addresses, and DNAT target, for those that alter destination addresses.

Three chains in the NAT table are used by the kernel for NAT operations. These are PREROUTING, POSTROUTING, and OUTPUT. PREROUTING is used for destination NAT (DNAT) rules. These are packets that are arriving. POSTROUTING is used for source NAT (SNAT) rules. These are for packets leaving. OUTPUT is used for destination NAT rules for locally generated packets.

As with packet filtering, you can specify source(-s) and destination (-d) addresses, as well as the input (-i) and output (-o) devices. The -j option will specify a target such as MASQUERADE. You would implement IP masquerading by adding a MASQUERADE rule to the POSTROUTING chain:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

To change the source address of a packet leaving your system, you would use the POSTROUTING rule with the SNAT target. For the SNAT target, you use the --to-source option to specify the source address:

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 192.168.0.4

To change the destination address of packets arriving on your system, you would use the PREROUTING rule with the DNAT target and the --to-destination option:

iptables -t nat -A PRETROUTING -i eth0 -j DNAT --to-destination 192.168.0.3

Specifying a port lets you change destinations for packets arriving on a particular port. In effect, this lets you implement port forwarding. In the next example, every packet arriving on port 80 (the Web service port) is redirected to 10.0.0.3, which in this case would be a system running a Web server.

iptables -t nat -A PRETROUTING -i eth0 -dport 80 -j DNAT --to-destination 10.0.0.3

With the TOS and MARK targets, you can mangle the packet to control its routing or priority. A TOS target sets the type of service for a packet, which can set the priority using criteria such as normal-service, minimize-cost, or maximize-throughput, among others.

The targets valid only for the NAT table are shown here:

SNAT

Modify source address, use --to-source option to specify new source address.

DNAT

Modify destination address, use --to-destination option to specify a new destination address.

REDIRECT

Redirect a packet.

MASQUERADE

IP masquerading.

MIRROR

Reverse source and destination and send back to the sender.

MARK

Modify the Mark field to control message routing.

Nat Redirection: Transparent Proxies

NAT tables can be used to implement any kind of packet redirection, a process transparent to the user. Redirection is commonly used to implement a transparent proxy. Redirection of packets is carried out with the REDIRECT target. With transparent proxies, packets received can be automatically redirected to a proxy server. For example, packets arriving on the Web service port, 80, can be redirected to the Squid Proxy service port, usually 3128. This involves a command to redirect a packet, using the REDIRECT target on the PREROUTING chain:

iptables -t nat -A PREROUTING -i eth1 --dport 80 -j REDIRECT --to-port 3128

Packet Mangling: the Mangle Table

The packet mangling table is used to actually modify packet information. Rules applied specifically to this table are often designed to control the mundane behavior of packets, like routing, connection size, and priority. Rules that actually modify a packet, rather than simply redirecting or stopping it, can be used only in the mangle table. For example, the TOS target can be used directly in the mangle table to change the Type of Service field to modifying a packet’s priority. A TCPMSS target could be set to control the size of a connection. The ECN target lets you work around ECN black holes, and the DSCP target will let you change DSCP bits. Several extensions such as the ROUTE extension will change a packet, in this case, rewriting its destination, rather than just redirecting it.

The mangle table is indicated with the -t mangle option. Use the following command to see what chains are listed in your mangle table:

iptables -t mangle  -L

Several mangle table targets are shown here:

TOS

Modify the Type of Service field to manage the priority of the packet.

TCPMSS

Modify the allowed size of packets for a connection, enabling larger transmissions.

ECN

Remove ECN black hole information.

DSCP

Change DSCP bits.

ROUTE

Extension TARGET to modify destination information in the packet.

Note: The IPtables package is designed to be extensible, allowing customized targets to be added easily. This involves applying patches to the kernel and rebuilding it. See https://netfilter.org/ for more details, along with a listing of extended targets.

Static Firewall Commands

The command used to execute packet filtering, NAT tasks, and packet mangling is iptables, and the software is commonly referred to as simply IPtables. However, Netfilter implements packet filtering and NAT tasks separately using different tables and commands. A table will hold the set of commands for its application. This approach streamlines the packet-filtering task, letting IPtables perform packet-filtering checks without the overhead of also having to do address translations. NAT operations are also freed from being mixed in with packet-filtering checks.

You use the iptables command for packet filtering, NAT tasks, and packet mangling. Each operation has its own table of rules: filter for packet filtering, nat for NAT tasks, and mangle for packet mangling. For NAT you specify the NAT table with the -t nat option. For the mangle table, you use the -t mangle option. The packet filtering is the default. It can be specified with the -t filter -t filter option, but it’s usually left out, assuming that if a table is not specified it is a filter operation. In addition, netfilter also handles certain exemptions to connection tracking operations in a raw table.

ip6tables

The ip6tables command provides support for IPv6 addressing. It is identical to IPtables except that it allows the use of IPv6 addresses instead of IPv4 addresses. Both filter and mangle tables are supported in ip6tables, but not NAT tables. The filter tables support the same options and commands as in IPtables. The mangle tables will allow specialized packet changes like those for IPtables, using PREROUTING, INPUT, OUTPUT, FORWARD, and POSTROUTING rules. Some extensions have ipv6 labels for their names, such as ipv6-icmp, which correspond to the IPtables icmp extension. The ipv6headers extension is used to select IPv6 headers.

arptables

The arptables tool allows you to manage rules for the IPv4 Address Resolution Protocol (ARP). The ARP is used on IPv4 local networks to discover the hardware address (MAC address) associated with an IP address. Once the association is made, connections can be made to that address. In this way, a host on a local network can detect and connect to another host. arptables sets up IPtables rules for controlling access between these hosts.  The filter, mangle, and nat tables are supported.

Install the arptables package. arptables has its own commands for saving and loading ARP rules, arptables-restore and arptables-save. It is used for managing transmissions on local networks.

ebtables

The ebtables tool manages rules for Ethernet bridges. Install the ebtables packages.  Configuration files are /etc/sysconfig/ebtables-config. ebtables uses ebtables-save and ebtables-restore to save and load ebtables rules.

xtables

xtables is an underlying framework that combines the code for iptables, ip6tables, and arptables.  Firewall modules hook into this framework.  Modules that connect directly to this framework begin the xt prefix.

Static Firewall using iptables

Support for older static IPtables rules is still implemented using various scripts and configuration files (see Table 4-8). The iptables unit file, iptables.service, runs the /usr/libexec/iptables/iptables.init script which manages the IPtables firewall. There is a corresponding unit file for IPv6, iptables6.service. Both are located in /lib/systemd/system. Be sure that the iptables-services package is installed.

sudo dnf install iptables-services

Be sure to enable iptables, and then start it.

sudo systemctl enable iptables
sudo systemctl start iptables

Script and Tool

Description

/etc/sysconfig/iptables

Fedora IPtables script to create IPtables rules

/etc/sysconfig/iptables.save

Fedora IPtables backup script to create IPtables rules. This is a copy made of original IPtables, when a new IPtables file is generated with the save option.

/etc/sysconfig/iptables-config

Configuration file for the iptables.init script, containing shell variable definitions.

/etc/rc.d/init.d/iptables

Fedora iptables service script to manage IPtables rules in /etc/sysconfig/iptables.

Table 4-8: Fedora IPtables Scripts and Tools

You should think of the iptables.init script that Fedora provides as a versatile management tool, not as a service startup script. The use of the systemctl command for this script can be confusing. The iptables script only manages IPtables rules, flushing, adding, or reporting them. It does not start and stop the IPtables service. If Netfilter is not running, you will need to specify that it be started up when your system boots.

The iptables.init script makes use of several predefined shell parameters for specifying modules along with start and stop options. Default definitions are placed within the iptables service script, whereas corresponding custom definitions are located in a special file called /etc/sysconfig/iptables-config. Here the system administrator can set options like what modules to load or whether to save rules whenever IPtables is stopped, without have to edit the IPtables service script directly. For IPv6, you would use ip6tables-config. Table 4-9 lists the current IPtables parameters. Each time the iptables service script is used to start IPtables, it will load the modules specified in IPTABLES_MODULES as listed in iptables-config.

Parameter

Description

IPTABLES_MODULES

List of IPtables modules to load. Empty by default.

IPTABLES_MODULES_UNLOAD

Default is yes, set to yes to unload modules at service script start and stop operations.

IPTABLES_SAVE_ON_STOP

Default is no, if set to yes, will save all rules when service script stops firewall.

IPTABLES_ SAVE_ON_RESTART

Default is no, if set to yes, will save all rules when service script restarts firewall.

IPTABLES_SAVE_COUNTERS

Default is no, if set to yes, will save counters if save for stopping or restarting is enabled.

IPTABLES_STATUS_NUMERIC

Default is yes, if set to yes, will display addresses and ports numerically.

Table 4-9: Configuration Parameters for iptables-config

The iptables.init and iptables6.init scripts operate much like the service script used in System V init, with start, stop, restart, and save options.  The status option displays a listing of all your current rules. The stop option will flush your current rules. Unlike stop and status, the start and save options are tied directly to the /etc/sysconfig/iptables file. The start option will flush your current IPtables rules and add those in the /etc/sysconfig/iptables file. The save option will save your current rules to the /etc/sysconfig/iptables file. Keep in mind that the stop and status operations work on the current IPtables rules, no matter if they were added manually on the command line, added by your own script, or added by the start option from /etc/sysconfig/iptables. The following command will list your current rules:

service iptables status

Perhaps the most effective way to think of the iptables service script is as an IPtables development tool. When creating complex firewall rules (beyond the simple set generated by system-config-firewall), you should first create a script and place your rules in them, as described later in the IPtables script example. Make the script executable. Any changes you need to make as you debug your firewall, you make to this script. Before you run it, run the iptables service script with the stop option to clear out any previous rules:

systemctl stop iptables

Then run your script, as shown here for the myfilters script:

./myfilters

To see how the commands have been interpreted by IPtables, use the service script with the status option:

systemctl status iptables

For any changes, edit your iptables script. Then run the service script again to clear out the old rules. Run the iptables script again, and use the status option with the service script to see how they were implemented:

sudo systemctl stop iptables
./myfilters
systemctl status iptables

Configuring Static IPtables with system-config-firewall

You can still use the older system-config-firewall desktop tool to configure iptables static firewalls. Download and install the system-config-firewall packages. You can start it from the Sundry | Firewall. Keep in mind that it conflicts with FirewallD. You will have to first stop firewalld before you can use system-config-firewall. 

sudo systemctl stop firewalld

To set up your firewall, run system-config-firewall (Sundry | Firewall) (see Figure 4-9). It should be the second firewall icon. The top button bar has buttons for a Firewall wizard, Apply button to effect any changes, Reload to restore your saved firewall, and Disable and Enable buttons. You can enable or disable your firewall with the Enable and Disable buttons. If the Firewall is active, only the Disable button can be used, and vice versa.

Figure 4-9: The system-config-firewall showing Firewall Trusted Services

A default configuration will already be in place. To create your own basic custom configuration just run the Wizard, by clicking the Wizard button.

You can also make changes directly to different firewall components. The Firewall Configuration window will show several tabs, selected from entries on a sidebar. The tabs are Trusted Services, Other Ports, Trusted Interfaces, Masquerading, and Custom Rules. 

The feature many users may want to change are the Trusted services. A Linux system is often used to run servers for a network. If you are creating a strong firewall but still want to run a service such as a Web server, an FTP server, Samba desktop browsing, or SSH encrypted connections, you must specify them in the Trusted Services tab. Samba desktop browsing lets you access your Samba shares, like remote Windows file systems, from your GNOME or KDE desktops.

The Other Ports tab lets you specify ports that you may want opened for certain services, like BitTorrent (see Figure 4-10). Click the Add button to open a dialog where you can select the port number along with the protocol to control (tcp or udp), or enter a specific port number or range.

Figure 4-10: Firewall Other Ports configuration

The Trusted interfaces tab lets you select those hardware network connections like NIC cards, modems, or wireless connections that can be trusted (see Figure 4-11). This is usually applied to interfaces connected to a local network or directly to a local router or server (like a print server). Interfaces connected to a wider network like the Internet should not be trusted.

Figure 4-11: Firewall Trusted Interfaces

If your system is being used as a gateway to the Internet for your local network, you can implement masquerading to hide your local hosts from outside access from the Internet (see Figure 4-12). This, though, also requires IP forwarding which is automatically enabled when you choose masquerading. Local hosts will still be able to access the Internet, but they will masquerade as your gateway system. You would select for masquerading the interface that is connected to the Internet. Masquerading is available only for IPv4 networks, not IPv6 networks.

The Port Forwarding tab lets you set up port forwarding, channeling transmissions from one port to another, or to a different port on another system.

Figure 4-12: Firewall Masquerading

The ICMP Filters tab allows you to block ICMP messages. By default, all ICMP messages are allowed. Blocking ICMP messages makes for a more secure system. Certain types of ICMP messages are often blocked as they can be used to infiltrate or overload a system, such as the ping and pong ICMP messages (see Figure 4-13).

Figure 4-13: ICMP Filters

Figure 4-14: Firewall Custom Rules

The Custom Rules tab lets you load an IP-tables file that can hold customized firewall rules (see Figure 4-14). Instead of having to choose whether to use system-config-firewall or to create an entire set of rules in an IP-tables file, you can use system-config-firewall to automatically configure the standard firewall rules and then set up an IP-tables file that holds only customized rules for your system. These are added to the standard set implemented by system-config-firewall. When you load the file you must determine whether the IPtables file holds IPv4 or IPv6 protocol rules (Address type). You also must select which table the firewall rules are meant for. There are three choices: filter (Netfilter rules), mangle (the mangle table used for rewriting addresses), and the nat table. Use the File button to open a browser to locate the IPtables file you want to load.

Saving IPtables rules

Once you are satisfied that your IPtables rules are working correctly, you can save your rules to the /etc/sysconfig/iptables file (for IPv6 you use /etc/sysconfig/ip6tables). Use the iptables service script with the save option. Now your rules will be read automatically when your system starts up. You can think of the save operation as installing your IPtables rules on your system, making them part of your system setup whenever you start your system.

sudo systemctl save iptables

To make changes, modify your iptables script, run the service script with stop to clear out the old rules, run the iptables script, and then use the service script with the save option to generate a new /etc/sysconfig/iptables file. A backup of the original is saved in /etc/sysconfig/iptables.save, in case you to need to restore the older rules.

Instead of using the service script, you can save your rules using the iptables-save script. The recommended file to use is /etc/iptables.rules. The service script actually used iptables-save with the -c option to save rules to the /etc/sysconfig/iptables file. The -c option for iptables-save includes counters in the output (the iptables service script is designed to parse counter information along with the commands). The iptables-save command outputs rules to the standard output. To save them in a file, you must redirect the output to a file with the redirection operator, >, as shown here:

iptables-save -c > /etc/sysconfig/iptables

You can also save your rules to a file of your choosing, such as /etc/iptables.rules. The /etc/rc.d/init.d/iptables service script defines the IPTABLES_CONFIG variable, which holds the name of the IPtables configuration file, /etc/sysconfig/iptables.

iptables-save > /etc/iptables.rules

Then, to restore the rules, use the iptables-restore script to read the IPtables commands from that saved file:

iptables-restore < /etc/iptables.rules

IPtables Scripts

Though you can enter IPtables rules from the shell command line, when you shut down your system, these commands will be lost. You will most likely need to place your IPtables rules in a script that can then be executed directly. This way you can edit and manage a complex set of rules, adding comments and maintaining their ordering.

An IPtables Script Example: IPv4

You now have enough information to create a simple IPtables script that will provide basic protection for a single system connected to the Internet. The following script, myfilter, provides an IPtables filtering process to protect a local network and a Web site from outside attacks. This example uses IPtables and IPv4 addressing. For IPv6 addressing, you would use ip6tables, which has corresponding commands, except for the NAT rules, which would be implemented as mangle rules. The older network device names,

 eth0 and eth1, are used here for clarity. Your system's actual device names will be different, following predictable naming formats (see Chapter 2).

The script configures a simple firewall for a private network (check the IPtables HOWTO for a more complex example). If you have a local network, you could adapt this script to it. In this configuration, all remote access initiated from the outside is blocked, but two-way communication is allowed for connections that users in the network make with outside systems. In this example, the firewall system functions as a gateway for a private network whose network address is 192.168.0.0 (see Figure 4-15). The Internet address is, for the sake of this example, 10.0.0.1. The system has two Ethernet devices: one for the private network (eth1) and one for the Internet (eth0). The gateway firewall system also supports a Web server at address 10.0.0.2. Entries in this example that are too large to fit on one line are continued on a second line, with the newline quoted with a backslash. The basic rules as they apply to different parts of the network are illustrated in Figure 4-16.

Initially, in the script, you would clear your current IPtables with the flush option (-F), and then set the policies (default targets) for the non-user-defined rules. IP forwarding should also be turned off while the chain rules are being set:

echo 0 > /proc/sys/net/ipv4/ip_forward

Figure 4-15: A network with a firewall

Figure 4-16: Firewall rules applied to a local network example

myfilter

Firewall Gateway system IP address is 10.0.0.1 using Ethernet device eth0
# Private network address is 192.168.0.0 using Ethernet device eth1
# Web site address is 10.0.0.2
# turn off IP forwarding
echo 0 > /proc/sys/net/ipv4/ip_forward
# Flush chain rules
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
# set default (policy) rules
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

# IP spoofing, deny any packets on the internal network that have an external source address.
iptables -A INPUT -j LOG  -i eth1 \! -s 192.168.0.0/24
iptables -A INPUT -j DROP  -i eth1 \! -s 192.168.0.0/24
iptables -A FORWARD -j DROP  -i eth1 \! -s 192.168.0.0/24
# IP spoofing, deny any outside packets (any not on eth1) that have the source address of the internal network
iptables -A INPUT -j DROP \! -i eth1 -s 192.168.0.0/24
iptables -A FORWARD -j DROP \! -i eth1 -s 192.168.0.0/24
# IP spoofing, deny any outside packets with localhost address
# (packets not on the lo interface (any on eth0 or eth1) that have the source address of localhost)
iptables -A INPUT -j DROP  -i \! lo  -s  127.0.0.0/255.0.0.0
iptables -A FORWARD -j DROP  -i \! lo  -s  127.0.0.0/255.0.0.0

# allow all incoming messages for users on your firewall system
iptables -A INPUT -j ACCEPT  -i lo

# allow  communication to the Web server (address 10.0.0.2), port www
iptables -A INPUT  -j ACCEPT -p tcp -i eth0  --dport www -s 10.0.0.2
# Allow  established connections from Web servers to internal network
iptables -A INPUT -m state --state ESTABLISHED,RELATED -i eth0 -p tcp  --sport www -s 10.0.0.2 -d 192.168.0.0/24  -j ACCEPT
# Prevent new  connections from Web servers to internal network
iptables -A OUTPUT -m state --state  NEW -o eth0 -p tcp  --sport www -d 192.168.0.0/24  -j DROP

# allow established and related outside communication to your system
# allow outside communication to the firewall, except for ICMP packets
iptables -A INPUT -m state --state ESTABLISHED,RELATED -i eth0 -p \! icmp -j ACCEPT
# prevent outside initiated connections
iptables -A INPUT -m state --state NEW -i eth0 -j DROP
iptables -A FORWARD -m state --state NEW -i eth0 -j DROP
# allow all local communication to and from the firewall on eth1  from the local network
iptables -A INPUT -j ACCEPT -p all -i eth1 -s 192.168.0.0/24
# Set up masquerading to allow internal machines access to outside network
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# Accept ICMP Ping and Destination unreachable messages
# Others will be rejected by INPUT and OUTPUT DROP policy
iptables -A INPUT -j ACCEPT  -p icmp -i eth0 --icmp-type  echo-reply -d 10.0.0.1
iptables -A INPUT -j ACCEPT  -p icmp -i eth0 --icmp-type  echo-request -d 10.0.0.1
iptables -A INPUT -j ACCEPT -p icmp -i eth0 --icmp-type  destination-unreachable -d 10.0.0.1
# Turn on IP Forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

Drop Policy

First, a DROP policy is set up for INPUT and FORWARD built-in IP chains. This means that if a packet does not meet a criterion in any of the rules to let it pass, it will be dropped. Then both IP spoofing attacks and any attempts from the outside to initiate connections (SYN packets) are rejected. Outside connection attempts are also logged. This is a very basic configuration that can easily be refined to your own needs by adding IPtables rules.

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

IP Spoofing

One way to protect the private network from the IP spoofing of any packets is to check for any outside addresses on the Ethernet device dedicated to the private network. In this example, any packet on device eth1 (dedicated to the private network) whose source address is not that of the private network (! -s 192.168.0.0) is denied. Also, check to see if any packets coming from the outside are designating the private network as their source. In this example, any packets with the source address of the private network on any Ethernet device other than for the private network (eth1) are denied. The same strategy can be applied to the local host.

# IP spoofing, deny any packets on the internal network
# that has an external source address.
iptables -A INPUT -j LOG  -i eth1 \! -s 192.168.0.0/24
iptables -A INPUT -j DROP  -i eth1 \! -s 192.168.0.0/24
iptables -A FORWARD -j DROP  -i eth1 \! -s 192.168.0.0/24
# IP spoofing, deny any outside packets (any not on eth1)
# that have the source address of the internal network
iptables -A INPUT -j DROP \! -i eth1 -s 192.168.0.0/24
iptables -A FORWARD -j DROP \! -i eth1 -s 192.168.0.0/24
# IP spoofing, deny any outside packets with localhost address
# (packets not on the lo interface (any on eth0 or eth1)
# that have the source address of localhost)
iptables -A INPUT -j DROP  -i \! lo  -s  127.0.0.0/255.0.0.0
iptables -A FORWARD -j DROP  -i \! lo  -s  127.0.0.0/255.0.0.0

Then, you would set up rules to allow all packets sent and received within your system (localhost) to pass.

iptables -A INPUT -j ACCEPT  -i lo

Server Access

For the Web server, you want to allow access by outside users but block access by anyone attempting to initiate a connection from the Web server into the private network. In the next example, all messages are accepted to the Web server, but the Web server cannot initiate contact with the private network. This prevents anyone from breaking into the local network through the Web server, which is open to outside access. Established connections are allowed, permitting the private network to use the Web server.

# allow  communication to the Web server (address 10.0.0.2), port www
iptables -A INPUT  -j ACCEPT -p tcp -i eth0  --dport www -s 10.0.0.2
# Allow  established connections from Web servers to internal network
iptables -A INPUT -m state --state ESTABLISHED,RELATED -i eth0 \
   -p tcp  --sport www -s 10.0.0.2 -d 192.168.0.0/24  -j ACCEPT
# Prevent new  connections from Web servers to internal network
iptables -A OUTPUT -m state --state  NEW -o eth0 -p tcp \
  --sport www -d 192.168.0.1.0/24  -j DROP

Firewall Outside Access

To allow access by the firewall to outside networks, you allow input by all packets except for ICMP packets. These are handled later. The firewall is specified by the firewall device, eth0. First, your firewall should allow established and related connections to proceed, as shown here. Then you would block outside access as described later.

# allow outside communication to the firewall,
# except for ICMP packets
iptables -A INPUT -m state --state ESTABLISHED,RELATED -i eth0 -p \! icmp -j ACCEPT

Blocking Outside Initiated Access

To prevent outsiders from initiating any access to your system, create a rule to block access by SYN packets from the outside using the state option with NEW. Drop any new connections on the eth0 connection (assumes only eth0 is connected to the Internet or outside network).

# prevent outside initiated connections
iptables -A INPUT -m state --state NEW -i eth0 -j DROP
iptables -A FORWARD -m state --state NEW -i eth0 -j DROP

Local Network Access

To allow interaction by the internal network with the firewall, you allow input by all packets on the internal Ethernet connection, eth1. The valid internal network addresses are designated as the input source.

iptables -A INPUT -j ACCEPT -p all -i eth1 -s 192.168.0.0/24

Listing Rules

A listing of these iptables options shows the different rules for each option, as shown here:

$ iptables -L
Chain INPUT (policy DROP)
target   prot opt source          destination
LOG      all  -- !192.168.0.0/24  anywhere        LOG level warning
DROP     all  -- !192.168.0.0/24  anywhere
DROP     all  --  192.168.0.0/24  anywhere
DROP     all  --  127.0.0.0/8     anywhere
ACCEPT   all  --  anywhere        anywhere
ACCEPT   tcp  --  10.0.0.2        anywhere        tcp dpt:http
ACCEPT   tcp  --  10.0.0.2        192.168.0.0/24  state RELATED,ESTABLISHED
                                                             tcp spt:http
ACCEPT  !icmp --  anywhere        anywhere        state RELATED,ESTABLISHED
DROP     all  --  anywhere        anywhere        state NEW
ACCEPT   all  --  192.168.0.0/24  anywhere
ACCEPT   icmp --  anywhere        10.0.0.1        icmp echo-reply
ACCEPT   icmp --  anywhere        10.0.0.1        icmp echo-request
ACCEPT   icmp --  anywhere        10.0.0.1        icmp destination-unreachable
Chain FORWARD (policy ACCEPT)
target   prot opt source          destination
DROP     all  -- !192.168.0.0/24  anywhere
DROP     all  --  192.168.0.0/24  anywhere
DROP     all  --  127.0.0.0/8     anywhere
DROP     all  --  anywhere        anywhere        state NEW

Chain OUTPUT (policy ACCEPT)
target   prot opt source       destination
DROP       tcp  --  anywhere     192.168.0.0/24  state NEW tcp spt:http

$ iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target      prot opt source       destination
Chain POSTROUTING (policy ACCEPT)
target      prot opt source       destination
MASQUERADE  all  --  anywhere      anywhere
Chain OUTPUT (policy ACCEPT)
target     prot opt source       destination

User-Defined Rules

For more complex rules, you may want to create your own chain to reduce repetition. A common method is to define a user chain for both INPUT and FORWARD chains so that you do not have to repeat DROP operations for each. Instead, you would have only one user chain that both FORWARD and INPUT chains would feed into for DROP operations. Keep in mind that both FORWARD and INPUT operations may have separate rules in addition to the ones they share. In the next example, a user-defined chain called arriving is created. The chain is defined with the -N option at the top of the script:

iptables -N arriving

A user chain has to be defined before it can be used as a target in other rules. So you have to first define and add all the rules for that chain, and then use it as a target. The arriving chain is first defined and its rules added. Then, at the end of the file, it is used as a target for both the INPUT and FORWARD chains. The INPUT chain lists rules for accepting packets, whereas the FORWARD chain has an ACCEPT policy that will accept them by default.

iptables -N arriving
iptables -F arriving
# IP spoofing, deny any packets on the internal network
# that has an external source address.
iptables -A arriving -j LOG  -i eth1 \! -s 192.168.0.0/24
iptables -A arriving -j DROP  -i eth1 \! -s 192.168.0.0/24
iptables -A arriving -j DROP \! -i eth1 -s 192.168.0.0/24
…………………………
# entries at end of script
iptables -A INPUT -j arriving
iptables -A FORWARD -j arriving

A listing of the corresponding rules is shown here:

Chain INPUT (policy DROP)
target    prot opt source          destination
arriving  all  --  0.0.0.0/0         0.0.0.0/0
Chain FORWARD (policy ACCEPT)
target    prot opt source          destination
arriving  all  --  0.0.0.0/0         0.0.0.0/0
Chain arriving (2 references)
target    prot opt source          destination
LOG       all  -- !192.168.0.0/24   0.0.0.0/0       LOG flags 0 level 4
DROP      all  -- !192.168.0.0/24   0.0.0.0/0
DROP      all  --  192.168.0.0/24   0.0.0.0/0

For rules where chains may differ, you will still need to enter separate rules. In the myfilter script, the FORWARD chain has an ACCEPT policy, allowing all forwarded packets to the local network to pass through the firewall. If the FORWARD chain had a DROP policy, like the INPUT chain, then you may need to define separate rules under which the FORWARD chain could accept packets. In this example, the FORWARD and INPUT chains have different rules for accepting packets on the eth1 device. The INPUT rule is more restrictive. To enable the local network to receive forwarded packets through the firewall, you could enable forwarding on its device using a separate FORWARD rule, as shown here:

iptables -A FORWARD -j ACCEPT -p all -i eth1

The INPUT chain would accept packets only from the local network.

iptables -A INPUT -j ACCEPT -p all -i eth1 -s 192.168.0.0/24

Masquerading Local Networks

To implement masquerading, where systems on the private network can use the gateway’s Internet address to connect to Internet hosts, you create a NAT table (-t nat) POSTROUTING rule with a MASQUERADE target.

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Controlling ICMP Packets

In addition, to allow ping and destination-reachable ICMP packets, you enter INPUT rules with the firewall as the destination. To enable ping operations, you use both echo-reply and echo-request ICMP types, and for destination unreachable, you use the destination-unreachable type.

iptables -A INPUT -j ACCEPT  -p icmp -i eth0 --icmp-type echo-reply -d 10.0.0.1
iptables -A INPUT -j ACCEPT  -p icmp -i eth0 --icmp-type echo-request -d 10.0.0.1
iptables -A INPUT -j ACCEPT -p icmp -i eth0 --icmp-type destination-unreachable -d 10.0.0.1

At the end, IP forwarding is turned on again.

echo 1 > /proc/sys/net/ipv4/ip_forward

Simple LAN Configuration

To create a script to support a simple LAN without any Internet services like Web servers, you would just not include rules for supporting those services. You would still need FORWARD and POSTROUTING rules for connecting your local hosts to the Internet, as well as rules governing interaction between the hosts and the firewall. To modify the example script to support a simple LAN without the Web server, just remove the three rules governing the Web server. Leave everything else the same.

LAN Configuration with Internet Services on the Firewall System

Often, the same system that functions as a firewall is also used to run Internet servers, like Web and FTP servers. In this case, the firewall rules are applied to the ports used for those services. The example script dealt with a Web server running on a separate host system. If the Web server were instead running on the firewall system, you would apply the Web server firewall rules to the port that the Web server uses. Normally the port used for a Web server is 80. In the following example, the IPtables rules for the Web server have been applied to port www, port 80, on the firewall system. The modification simply requires removing the old Web server host address references, 10.0.0.2.

# allow  communication to the Web server, port www (port 80)
iptables -A INPUT  -j ACCEPT -p tcp -i eth0  --dport www
# Allow  established connections from Web servers to internal network
iptables -A INPUT -m state --state ESTABLISHED,RELATED -i eth0 \
   -p tcp  --sport www -d 192.168.0.0/24  -j ACCEPT
# Prevent new  connections from Web servers to internal network
iptables -A OUTPUT -m state --state  NEW -o eth0 -p tcp \
  --sport www -d 192.168.0.1.0/24 -j DROP

Similar entries could be set up for an FTP server. Should you run several Internet services, you could use a user-defined rule to run the same rules on each service, rather than repeating three separate rules per service. Working from the example script, you would use two defined rules, one for INPUT and one for OUTPUT, controlling incoming and outgoing packets for the services.

iptables -N inputservice
iptables -N outputservice
iptables -F inputservice
iptables -F outputservice
# allow  communication to the service
iptables -A inputservice  -j ACCEPT -p tcp -i eth0
# Allow  established connections from the service to internal network
iptables -A inputservice -m state --state ESTABLISHED,RELATED -i eth0 \
   -p tcp  -d 192.168.0.0/24  -j ACCEPT
# Prevent new  connections from service to internal network
iptables -A outputservice -m state --state  NEW -o eth0 -p tcp \
  -d 192.168.0.1.0/24 -j DROP
…………………………
# Run rules for the Web server, port www (port 80)
iptables -A INPUT  --dport www -j inputservice
iptables -A INPUT  --dport www -j outputservice
# Run rules for the FTP server, port ftp (port 21)
iptables -A OUTPUT  --dport ftp -j inputservice
iptables -A OUTPUT  --dport ftp -j outputservice

IP Masquerading

On Linux systems, you can set up a network in which you can have one connection to the Internet, which several systems on your network can use. This way, using only one IP address, several different systems can connect to the Internet. This method is called IP masquerading, where a system masquerades as another system, using that system’s IP address. In such a network, one system is connected to the Internet with its own IP address, while the other systems are connected on a local area network (LAN) to this system. When a local system wants to access the network, it masquerades as the Internet-connected system, borrowing its IP address.

IP masquerading is implemented on Linux using the IPtables firewall tool. In effect, you set up a firewall, which you then configure to do IP masquerading. You can find out more information on IP masquerading from the Linux Masquerade HOWTO files at the Linux Documentation Project, https://tldp.org, where you’ll find both an IP-Masquerade-HOWTO and a Masquerading-Simple-HOWTO. They provide detailed, step-by-step guides to setting up IP masquerading on your system. IP masquerading must be supported by the kernel before you can use it.

With IP masquerading, as implemented on Linux systems, the machine with the Internet address is also the firewall and gateway for the LAN of machines that use the firewall’s Internet address to connect to the Internet. Firewalls that also implement IP masquerading are sometimes referred to as MASQ gates. With IP masquerading, the Internet-connected system (the firewall) listens for Internet requests from hosts on its LAN. When it receives one, it replaces the requesting local host’s IP address with the Internet IP address of the firewall and then passes the request out to the Internet, as if the request were its own. Replies from the Internet are then sent to the firewall system. The replies the firewall receives are addressed to the firewall using its Internet address. The firewall then determines the local system to whose request the reply is responding. It then strips off its IP address and sends the response on to the local host across the LAN. The connection is transparent from the perspective of the local machines. They appear to be connected directly to the Internet.

Masquerading Local Networks

IP masquerading is often used to allow machines on a private network to access the Internet. These could be machines in a home network or a small LAN, such as for a small business. Such a network might have only one machine with Internet access, and as such, only the one Internet address. The local private network would have IP addresses chosen from the private network allocations (10., 172.16., or 192.168.). Ideally, the firewall has two Ethernet cards: one for an interface to the LAN (for example, eth1) and one for an interface to the Internet, such as eth0 (for dial-up ISPs, this would be ppp0 for the modem). The card for the Internet connection (eth0) would be assigned the Internet IP address. The Ethernet interface for the local network (eth1, in this example) is the firewall Ethernet interface. Your private LAN would have a network address like 192.168.0. Its Ethernet firewall interface (eth1) would be assigned the IP address 192.168.0.1. In effect, the firewall interface lets the firewall operate as the local network’s gateway. The firewall is then configured to masquerade any packets coming from the private network. Your LAN needs to have its own domain name server, identifying the machines on your network, including your firewall. Each local machine needs to have the firewall specified as its gateway. Try not to use IP aliasing to assign both the firewall and Internet IP addresses to the same physical interface. Use separate interfaces for them, such as two Ethernet cards, or an Ethernet card and a modem (ppp0).

Masquerading NAT Rules

In Netfilter, IP masquerading is a NAT operation and is not integrated with packet filtering as in IP Chains. IP masquerading commands are placed on the NAT table and treated separately from the packet-filtering commands.

Masquerading is enabled for zones on FirewallD using the firewall-config Masquerading tab, or the firewall-cmd --add-masquerade option. Use the --remove-masquerade option to remove it from a zone.

sudo firewall-cmd --permanent  --zone=work -add-masquerade

For a static firewall, you can use iptables to place a masquerade rule on the NAT table. First, reference the NAT table with the -t nat option. Then add a rule to the POSTROUTING chain with the -o option specifying the output device and the -j option with the MASQUERADE command.

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

The next step is to turn on IP forwarding, either manually or by setting the net.ipv4.ip_forward variable in the /etc/sysctl.conf file and running sysctl with the -p option. IP forwarding will be turned off by default. For IPv6, use net.ipv6.conf.all.forwarding. The /etc/sysctl.conf entries are shown here:

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

You then run sysctl with the -p option.

sysctl -p

You can directly change the respective forwarding files with an echo command as shown here:

sudo echo 1 > /proc/sys/net/ipv4/conf/all/forwarding

For IPv6, you would use the forwarding file in the corresponding /proc/sys/net/ipv6 directory, conf/all/forwarding.

sudo echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

Masquerading Selected Hosts

Instead of masquerading all local hosts as the single IP address of the firewall/gateway host, you could use the NAT table to rewrite addresses for a few selected hosts. Such an approach is often applied to setups where you want several local hosts to appear as Internet servers. Using the DNAT and SNAT targets, you can direct packets to specific local hosts. You would use rules on the PREROUTING and POSTROUTING chains to direct input and output packets.

For example, the Web server described in the previous example could have been configured as a local host to which a DNAT target could redirect any packets originally received for 10.0.0.2. Say the Web server was set up on 192.168.0.5. It could appear as having the address 10.0.0.2 on the Internet. Packets sent to 10.0.0.2 would be rewritten and directed to 192.168.0.5 by the NAT table. You would use the PREROUTING chain with the -d option to handle incoming packets and POSTROUTING with the -s option for outgoing packets.

iptables -t nat -A PREROUTING -d 10.0.0.2 --to-destination 192.168.0.5 -j DNAT
iptables -t nat -A POSTROUTING -s 192.168.0.5 --to-source 10.0.0.2 -j SNAT

Tip: Bear in mind that with IPtables, masquerading is not combined with the FORWARD chain, as it is with IP Chains. So, if you specify a DROP policy for the FORWARD chain, you will also have to specifically enable FORWARD operation for the network that is being masqueraded. You will need both a POSTROUTING rule and a FORWARD rule.

5. Shell Variables and Scripts

A shell script combines Linux commands in such a way as to perform a specific task. The different kinds of shells provide many programming tools that you can use to create shell scripts. You can define variables and assign values to them. You can also define variables in a script file, and have a user interactively enter values for them when the script is executed. The shell provides loop and conditional control structures that repeat Linux commands or make decisions on which commands you want to execute. You can also construct expressions that perform arithmetic or comparison operations. All these shell programming tools operate in ways similar to those found in other programming languages, so if you’re already familiar with programming, you might find shell programming simple to learn.

The BASH, TCSH, and Z shells are types of shells. You can have many instances of a particular kind of shell. A shell, by definition, is an interpretive environment within which you execute commands. You can have many environments running at the same time, of either the same or different types of shells; you have several shells running at the same time that are of the BASH shell type, for example.

This chapter will cover the basics of creating a shell script using the BASH and TCSH shells, the shells used on most Linux systems. You will learn how to create your own scripts, define shell variables, and develop user interfaces, as well as learn the more difficult task of combining control structures to create complex programs. Tables throughout the chapter list shell commands and operators, while numerous examples show how they are implemented.

Usually, the instructions making up a shell program are entered into a script file that can then be executed. You can even distribute your program among several script files, one of which will contain instructions on how to execute others. You can think of variables, expressions, and control structures as tools you can use to bring together several Linux commands into one operation. In this sense, a shell program is a new and complex Linux command that you have created.

The BASH shell has a flexible and powerful set of programming commands that allows you to build complex scripts. It supports variables that can be either local to the given shell or exported to other shells. You can pass arguments from one script to another. The BASH shell has a complete set of control structures, including loops and if statements, as well as case structures, all of which you’ll learn about as you read this book. All shell commands interact easily with redirection and piping operations that allow them to accept input from the standard input or send it to the standard output. Unlike the Bourne shell, the first shell used for UNIX, BASH incorporates many of the features of the TCSH and Z shells. Arithmetic operations, in particular, are easier to perform in BASH.

Shell Variables

Within each shell, you can enter and execute commands. You can further enhance the capabilities of a shell using shell variables. A shell variable lets you hold data that you can reference over and over again as you execute different commands within a shell. For example, you can define a shell variable to hold the name of a complex filename. Then, instead of retyping the filename in different commands, you can reference it with the shell variable.

You define variables within a shell, and such variables are known as shell variables. Some utilities, such as the Mail utility, have their own shells with their own shell variables. You can also create your own shell using shell scripts. You have a user shell that becomes active as soon as you log in. This is often referred to as the login shell. Special system-level parameter variables are defined within this login shell. Shell variables can also be used to define a shell’s environment.

Note: Shell variables exist as long as your shell is active—that is, until you exit the shell. For example, logging out will exit the login shell. When you log in again, any variables you may need in your login shell must be defined again.

Definition and Evaluation of Variables: =, $, set, unset

You define a variable in a shell when you first use the variable’s name. A variable’s name may be any set of alphabetic characters, including the underscore. The name may also include a number, but the number cannot be the first character in the name. A name may not have any other type of character, such as an exclamation point, an ampersand, or even a space. Such symbols are reserved by the shell for its own use. Also, a variable name may not include more than one word. The shell uses spaces on the command line to distinguish different components of a command such as options, arguments, and the command name.

You assign a value to a variable with the assignment operator (=). You type the variable name, the assignment operator, and then the value assigned. Do not place any spaces around the assignment operator. The assignment operation poet = Virgil, for example, will fail. (The C shell has a slightly different type of assignment operation.) You can assign any set of characters to a variable. In the next example, the variable poet is assigned the string Virgil:

$ poet=Virgil

Once you have assigned a value to a variable, you can use the variable name to reference the value. Often you use the values of variables as arguments for a command. You can reference the value of a variable using the variable name preceded by the $ operator. The dollar sign is a special operator that uses the variable name to reference a variable’s value, in effect evaluating the variable. Evaluation retrieves a variable’s value, usually a set of characters. This set of characters then replaces the variable name on the command line. Wherever a $ is placed before the variable name, the variable name is replaced with the value of the variable. In the next example, the shell variable poet is evaluated and its contents, Virgil, is used as the argument for an echo command. The echo command simply echoes or prints a set of characters to the screen.

$ echo $poet
Virgil

You must be careful to distinguish between the evaluation of a variable and its name alone. If you leave out the $ operator before the variable name, all you have is the variable name itself. In the next example, the $ operator is absent from the variable name. In this case, the echo command has as its argument the word poet, and so prints out poet:

$ echo poet
poet

The contents of a variable are often used as command arguments. A common command argument is a directory pathname. It can be tedious to retype a directory path that is being used over and over again. If you assign the directory pathname to a variable, you can simply use the evaluated variable in its place. The directory path you assign to the variable is retrieved when the variable is evaluated with the $ operator. The next example assigns a directory pathname to a variable, and then uses the evaluated variable in a copy command. The evaluation of ldir (which is $ldir) results in the pathname /home/chris/letters. The copy command evaluates to cp myletter /home/chris/letters.

$ ldir=/home/chris/letters
$ cp myletter $ldir

You can obtain a list of all the defined variables with the set command. If you decide you do not want a certain variable, you can remove it with the unset command. The unset command undefines a variable.

Variable Values: Strings

The values that you assign to variables may consist of any set of characters. These characters may be a character string that you explicitly type in or the result obtained from executing a Linux command. In most cases, you will need to quote your values using either single quotes, double quotes, backslashes, or back quotes. Single quotes, double quotes, and backslashes allow you to quote strings in different ways. Back quotes have the special function of executing a Linux command and using its results as arguments on the command line.

Quoting Strings: Double Quotes, Single Quotes, and Backslashes

Variable values can be made up of any characters. However, problems occur when you want to include characters that are also used by the shell as operators. Your shell has certain metacharacters that it uses in evaluating the command line. A space is used to parse arguments on the command line. The asterisk, question mark, and brackets are metacharacters used to generate lists of filenames. The period represents the current directory. The dollar sign, $, is used to evaluate variables, and the greater-than and less-than characters , > <, are redirection operators. The ampersand, &, is used to execute background commands and the bar pipes output. If you want to use any of these characters as part of the value of a variable, you first need to quote them. Quoting a metacharacter on a command line makes it just another character. It is not evaluated by the shell.

You can use double quotes, single quotes, and backslashes to quote such metacharacters. Double and single quotes allow you to quote several metacharacters at a time. Any metacharacters within double or single quotes are quoted. A backslash quotes the single character that follows it.

If you want to assign more than one word to a variable, you need to quote the spaces separating the words. You can do so by enclosing all the words within double quotes. You can think of this as creating a character string to be assigned to the variable. Of course, any other metacharacters enclosed within the double quotes are also quoted.

In the following first example, the double quotes enclose words separated by spaces. Because the spaces are enclosed within double quotes, they are treated as characters, not as delimiters used to parse command line arguments. In the second example, double quotes also enclose a period, treating it as just a character. In the third example, an asterisk is also enclosed within the double quotes. The asterisk is considered just another character in the string and is not evaluated.

$ notice="The meeting will be tomorrow"
$ echo $notice
The meeting will be tomorrow

$ message="The project is on time."
$ echo $message
The project is on time.

$ notice="You can get a list of files with ls *.c"
$ echo $notice
You can get a list of files with ls *.c

Double quotes, however, do not quote the dollar sign, the operator that evaluates variables. A $ operator next to a variable name enclosed within double quotes will still be evaluated, replacing the variable name with its value. The value of the variable will then become part of the string, not the variable name. There may be times when you want a variable within quotes to be evaluated. In the next example, the double quotes are used so that the winner's name will be included in the notice.

$ winner=dylan
$ notice="The person who won is $winner"
$ echo $notice
The person who won is dylan

On the other hand, there may be times when you do not want a variable within quotes to be evaluated. In that case, you have to use the single quotes. Single quotes suppress any variable evaluation and treat the dollar sign as just another character. In the next example, single quotes prevent the evaluation of the winner variable.

$ winner=dylan
$ result='The name is in the $winner variable'
$ echo $result
The name is in the $winner variable

If in this case, the double quotes were used instead, an unintended variable evaluation would take place. In the next example, the characters "$winner" are interpreted as a variable evaluation.

$ winner=dylan
$ result="The name is in the $winner variable"
$ echo $result
The name is in the dylan variable

You can always quote any metacharacter, including the $ operator, by preceding it with a backslash. The use of the backslash is to quote enter keys (newlines). The backslash is useful when you want to both evaluate variables within a string and include $ characters. In the next example, the backslash is placed before the $ in order to treat it as a dollar sign character: \$. At the same time, the variable $winner is evaluated because the double quotes that are used do not quote the $ operator.

$ winner=dylan
$ result="$winner won \$100.00"
$ echo $result
dylan won $100.00

Quoting Commands: Single Quotes

There are, however, times when you may want to use single quotes around a Linux command. Single quotes allow you to assign the written command to a variable. If you do so, you can then use that variable name as another name for the Linux command. Entering in the variable name, preceded by the $ operator on the command line, will execute the command. In the next example, a shell variable is assigned the characters that make up a Linux command to list files, 'ls -F'. Notice the single quotes around the command. When the shell variable is evaluated on the command line, the Linux command it contains will become a command line argument, and it will be executed by the shell.

$ lsf='ls -F'
$ $lsf
mydata /reports /letters
$

In effect, you are creating another name for a command, like an alias.

Values from Linux Commands: Back Quotes

Although you can create variable values by typing in characters or character strings, you can also obtain values from other Linux commands. To assign the result of Linux command to a variable, you first need to execute the command. If you place a Linux command within back quotes(`) on the command line, that command is first executed and its result becomes an argument on the command line. In the case of assignments, the result of a command can be assigned to a variable by placing the command within back quotes first to execute it. The back quotes can be thought of as an expression consisting of a command to be executed whose result is then assigned to the variable. The characters making up the command itself are not assigned. In the next example, the command ls *.c is executed and its result is then assigned to the variable listc. ls *.c, which generates a list of all files with a .c extension. This list of files is then assigned to the listc variable.

$ listc=`ls `*.c`
$ echo $listc
main.c prog.c lib.c

Keep in mind the difference between single quotes and back quotes. Single quotes treat a Linux command as a set of characters. Back quotes force execution of the Linux command. There may be times when you accidentally enter single quotes when you mean to use back quotes. In the following first example, the assignment for the lscc variable has single quotes, not back quotes, placed around the ls *.c command. In this case, ls *.c are just characters to be assigned to the variable lscc. In the second example, back quotes are placed around the ls *.c command, forcing evaluation of the command. A list of filenames ending in .c is generated and assigned as the value of lscc.

$ lscc='ls *.c'
$ echo $lscc
ls *.c

$ lscc=`ls *.c`
$ echo $lscc
main.c  prog.c

Shell Scripts: User-Defined Commands

You can place shell commands within a file and then have the shell read and execute the commands in the file. In this sense, the file functions as a shell program, executing shell commands as if they were statements in a program. A file that contains shell commands is called a shell script.

You enter shell commands into a script file using a standard text editor such as the Vi editor. The sh or . command used with the script’s filename will read the script file and execute the commands. In the next example, the text file called lsc contains an ls command that displays only files with the extension .c:

lsc

ls *.c

A run of the lsc script is shown here:

$ sh lsc
main.c calc.c
$ . lsc
main.c calc.c

Executing Scripts

You can dispense with the sh and . commands by setting the executable permission of a script file. When the script file is first created by your text editor, it is given only read and write permission. The chmod command with the +x option will give the script file executable permission. Once it is executable, entering the name of the script file at the shell prompt and pressing enter will execute the script file and the shell commands in it. In effect, the script’s filename becomes a new shell command. In this way, you can use shell scripts to design and create your own Linux commands. You need to set the permission only once.

In the next example, the lsc file’s executable permission for the owner is set to on. Then the lsc shell script is directly executed like any Linux command.

$ chmod u+x lsc
$ lsc
main.c calc.c

You may have to specify that the script you are using is in your current working directory. You do this by prefixing the script name with a period and slash combination, as in ./lsc. The period is a special character representing the name of your current working directory. The slash is a directory pathname separator. The following example shows how to execute the lsc script:

$ ./lsc
main.c calc.c

Script Arguments

Just as any Linux command can take arguments, so also can a shell script. Arguments on the command line are referenced sequentially starting with 1. An argument is referenced using the $ operator and the number of its position. The first argument is referenced with $1, the second, with $2, and so on. In the next example, the lsext script prints out files with a specified extension. The first argument is the extension. The script is then executed with the argument c (of course, the executable permission must have been set).

lsext

ls *.$1

A run of the lsext script with an argument is shown here:

$ lsext c
main.c calc.c

In the next example, the commands to print out a file with line numbers have been placed in an executable file called lpnum, which takes a filename as its argument. The cat command with the -n option first outputs the contents of the file with line numbers. Then this output is piped into the lpr command, which prints it. The command to print out the line numbers is executed in the background.

lpnum

cat -n $1 | lpr &

A run of the lpnum script with an argument is shown here:

$ lpnum mydata

You may need to reference more than one argument at a time. The number of arguments used may vary. In lpnum, you may want to print out three files at one time and five files at some other time. The $ operator with the asterisk, $*, references all the arguments on the command line. Using $* enables you to create scripts that take a varying number of arguments. In the next example, lpnum is rewritten using $* so that it can take a different number of arguments each time you use it:

lpnum

cat -n $* | lpr &

A run of the lpnum script with multiple arguments is shown here:

$ lpnum mydata preface

Environment Variables

When you log in to your account, your Linux system generates your user shell. Within this shell, you can issue commands and declare variables. You can also create and execute shell scripts. However, when you execute a shell script, the system generates a subshell. You then have two shells, the one you logged in to and the one generated for the script. Within the script shell, you can execute another shell script, which will then have its own shell. When a script has finished execution, its shell terminates and you enter back to the shell from which it was executed. In this sense, you can have many shells, each nested within the other.

Variables that you define within a shell are local to it. If you define a variable in a shell script, then, when the script is run, the variable is defined with that script's shell and is local to it. No other shell can reference it. In a sense, the variable is hidden within its shell.

To illustrate this situation more clearly, the next example will use two scripts, one of which is called from within the other. When the first script executes, it generates its own shell. From within this shell, another script is executed which, in turn, generates its own shell. In the next example, the user first executes the dispfirst script, which displays a first name. When the dispfirst script executes, it generates its own shell and then, within that shell, it defines the firstname variable. After it displays the contents of firstname, the script executes another script: displast. When displast executes, it generates its own shell. It defines the lastname variable within its shell and then displays the contents of lastname. It then tries to reference firstname and display its contents. It cannot do so because firstname is local to dispfirst's shell and cannot be referenced outside it. An error message is displayed indicating that for the displast shell, firstname is an undefined variable.

dispfirst

firstname="Charles"
echo "First name is $firstname"

displast

displast

lastname="Dickens"

echo "Last name is $lastname"
echo "$firstname $lastname"

The run of the dispfirst script is shown here:

$ dispfirst
First name is Charles
Last name is Dickens
Dickens
sh: firstname: not found

If you want the same value of a variable, used both in a script's shell and a subshell, you can simply define the variable twice, once in each script, and assign it the same value. In the previous example, there is a myfile variable defined in dispfile and in printfile. The user executes the b script, which first displays the list file with line numbers. When the dispfile script executes, it generates its own shell and then, within that shell, it defines the myfile variable. After it displays the contents of the file, the script then executes another script printfile. When printfile executes, it generates its own shell. It defines its own myfile variable within its shell and then sends a file to the printer.

What if you want to define a variable in one shell and have its value referenced in any subshell? For example, what if you want to define the myfile variable in the dispfile script and have its value, "List", referenced from within the printfile script, rather than explicitly defining another variable in printfile? Since variables are local to the shell they are defined in, there is no way you can do this with ordinary variables. However, there is a type of variable called an environment variable that allows its value to be referenced by any subshells. Environment variables constitute an environment for the shell and any subshell it generates, no matter how deeply nested.

dispfile

myfile="List"

echo "Displaying $myfile"
pr -t -n $myfile

printfile

printfile

myfile="List"

echo "Printing $myfile"
lp $myfile &

The run of the dispfile script is shown here:

$ dispfile
Displaying List
1 screen
2 modem
3 paper
Printing List

You can define environment variables in the three major types of shells: Bourne, Korn, and C. However, the strategy used to implement environmental variables in the Bourne and Korn shells is very different from that of the C shell. In the Bourne and Korn shells, environmental variables are exported. That is to say, a copy of an environmental variable is made in each subshell. In a sense, if the myfile variable is exported, a copy is automatically defined in each subshell for you. In the C shell, on the other hand, an environmental variable is defined only once and can be directly referenced by any subshell.

Shell Environment Variables

In the Bourne, BASH, and Korn shells, an environment variable can be thought of as a regular variable with added capabilities. To make an environment variable, you apply the export command to a variable you have already defined. The export command instructs the system to define a copy of that variable for each new shell generated. Each new shell will have its own copy of the environment variable. This process is called exporting variables.

In the next example, the variable myfile is defined in the dispfile script. It is then turned into an environment variable using the export command. The myfile variable will consequently be exported to any subshells, such as that generated when printfile is executed.

dispfile

myfile="List"
export myfile

echo "Displaying $myfile"
pr -t -n $myfile

printfile

printfile

echo "Printing $myfile"
lp $myfile &

The run of the dispfile script is shown here:

$ dispfile
Displaying List
1 screen
2 modem
3 paper
Printing List

When printfile is executed it will be given its own copy of myfile and can reference that copy within its own shell. You no longer need to explicitly define another myfile variable in printfile.

It is a mistake to think of exported environment variables as global variables. A new shell can never reference a variable outside of itself. Instead, a copy of the variable with its value is generated for the new shell. You can think of exported variables as exporting their values to a shell, not themselves. For those familiar with programming structures, exported variables can be thought of as a form of call-by-value.

Control Structures

You can control the execution of Linux commands in a shell script with control structures. Control structures allow you to repeat commands and to select certain commands over others. A control structure consists of two major components: a test and commands. If the test is successful, then the commands are executed. In this way, you can use control structures to make decisions as to whether commands should be executed.

Two different kinds of control structures are used: loops, which repeat commands, and conditions, which execute commands when certain conditions are met. The BASH shell has three loop control structures—while, for, and for-in—and two condition structures—if and case. The control structures have as their test the execution of a Linux command. All Linux commands return an exit status after they have finished executing. If a command is successful, its exit status will be 0. If the command fails for any reason, its exit status will be a positive value referencing the type of failure that occurred. The control structures check to see whether the exit status of a Linux command is 0 or some other value. In the case of the if and while structures, if the exit status is a 0 value, the command was successful and the structure continues.

Test Operations

With the test command, you can compare integers and strings, and even perform logical operations. The command consists of the keyword test, followed by the values being compared, separated by an option that specifies what kind of comparison is taking place. The option can be thought of as the operator, but it is written, like other options, with a minus sign and letter codes. For example, -eq is the option that represents the equality comparison. Two string operations, however, actually use an operator instead of an option. When you compare two strings for equality, you use the equal sign (=). For inequality you use !=. Table 5-1 lists some of the commonly used options and operators used by test. The syntax for the test command is shown here:

test value -option value
test string = string

Integer Comparisons

Function

-gt

Greater-than

-lt

Less-than

-ge

Greater-than-or-equal-to

-le

Less-than-or-equal-to

-eq

Equal

-ne

Not-equal

String Comparisons

-z

Tests for empty string

=

Equal strings

!=

Not-equal strings

Logical Operations

-a

Logical AND

-o

Logical OR

!

Logical NOT

File Tests

-f

File exists and is a regular file

-s

File is not empty

-r

File is readable

-w

File can be written to, modified

-x

File is executable

-d

Filename is a directory name

Table 5-1: BASH Shell Test Operators

The next example compares two integer values to determine whether they are equal. In this case, the equality option, -eq, should be used. The exit status of the test command is examined to determine the result of the test operation. The shell special variable $? holds the exit status of the most recently executed Linux command.

$ num=5
$ test $num -eq 10
$ echo $?
1

Instead of using the keyword test for the test command, you can use enclosing brackets. The command test $greeting = "hi" can be written as

$ [ $greeting = "hi" ]

Similarly, the command test $num -eq 10 can be written as

$ [ $num -eq 10 ]

The brackets themselves must be surrounded by white space: a space, tab, or enter. Without the spaces, the code is invalid.

Conditional Control Structures

The BASH shell has a set of conditional control structures that allow you to choose what Linux commands to execute. Many of these are similar to conditional control structures found in programming languages, but there are some differences. The if condition tests the success of a Linux command, not an expression. Furthermore, the end of an if-then command must be indicated with the keyword fi, and the end of a case command is indicated with the keyword esac. The condition control structures are listed in Table 5-2.

The if structure places a condition on commands. That condition is the exit status of a specific Linux command. If a command is successful, returning an exit status of 0, then the commands within the if structure are executed. If the exit status is anything other than 0, the command has failed and the commands within the if structure are not executed. The if command begins with the keyword if and is followed by a Linux command whose exit condition will be evaluated. The keyword fi ends the command.

The elsels script in the next example executes the ls command to list files with two different possible options, either by size or with all file information. If the user enters an s, files are listed by size; otherwise, all file information is listed.

elsels

echo Enter s to list file sizes,
echo       otherwise all file information is listed.
echo -n "Please enter option: "
read choice
if [  "$choice" = s  ]
    then
        ls -s
    else
           ls -l
fi
echo Good-bye

Condition Control Structures:
if, else, elif, case

Function

if command then
command
fi

if executes an action if its test command is true.

if command then
command
else
command
fi

if-else executes an action if the exit status of its test command is true; if false, the else action is executed.

if command then
command
elif command then
command
else
command
fi

elif allows you to nest if structures, enabling selection among several alternatives; at the first true if structure, its commands are executed and control leaves the entire elif structure.

case string in
pattern)
command;;
esac

case matches the string value to any of several patterns; if a pattern is matched, its associated commands are executed.

command && command

The logical AND condition returns a true 0 value if both commands return a true 0 value; if one returns a nonzero value, then the AND condition is false and also returns a nonzero value.

command || command

The logical OR condition returns a true 0 value if one or the other command returns a true 0 value; if both commands return a nonzero value, then the OR condition is false and also returns a nonzero value.

! command

The logical NOT condition inverts the return value of the command.

Loop Control Structures:
while, until, for, for-in, select

while command
do
command
done

while executes an action as long as its test command is true.

until command
do
command
done

until executes an action as long as its test command is false.

for variable in list-values
do
command
done

for-in is designed for use with lists of values; the variable operand is consecutively assigned the values in the list.

for variable
do
command
done

for is designed for reference script arguments; the variable operand is consecutively assigned each argument value.

select string in item-list
do
command
done

select creates a menu based on the items in the item-list; then it executes the command; the command is usually a case.

Table 5-2: BASH Shell Control Structures

A run of the program follows:

$ elsels
Enter s to list file sizes,
otherwise all file information is listed.
Please enter option: s
total 2
    1 monday     2 today

Loop Control Structures

The while loop repeats commands. A while loop begins with the keyword while and is followed by a Linux command. The keyword do follows on the next line. The end of the loop is specified by the keyword done. The Linux command used in while structures is often a test command indicated by enclosing brackets.

The for-in structure is designed to reference a list of values sequentially. It takes two operands: a variable and a list of values. The values in the list are assigned one by one to the variable in the for-in structure. Like the while command, the for-in structure is a loop. Each time through the loop, the next value in the list is assigned to the variable. When the end of the list is reached, the loop stops. Like the while loop, the body of a for-in loop begins with the keyword do and ends with the keyword done. The cbackup script makes a backup of each file and places it in a directory called sourcebak. Notice the use of the * special character to generate a list of all filenames with a .c extension.

cbackup

for backfile in *.c
do
    cp $backfile sourcebak/$backfile
echo $backfile
done

A run of the program follows:

$ cbackup
io.c
lib.c
main.c
$

The for structure without a specified list of values takes as its list of values the command line arguments. The arguments specified on the command line when the shell file is invoked become a list of values referenced by the for command. The variable used in the for command is set automatically to each argument value in sequence. The first time through the loop, the variable is set to the value of the first argument. The second time, it is set to the value of the second argument.

Part 2:  Internet Servers

6. Mail Servers

7. FTP

8. Web Servers

9. News and Database Services

6. Mail Servers

Mail servers provide Internet users with electronic mail services. They have their own TCP/IP protocols such as the Simple Mail Transfer Protocol (SMTP), the Post Office Protocol (POP), and the Internet Mail Access Protocol (IMAP). Messages are sent across the Internet through mail servers that service local domains. A domain can be seen as a subnet of the larger Internet, with its own server to handle mail messages sent from or received for users on that subnet. When a user emails a message, it is first sent from the user's host system to the mail server. The mail server then sends the message to another mail server on the Internet, the one servicing the subnet on which the recipient user is located. The receiving mail server then sends the message to the recipient’s host system.

At each stage, a different type of operation takes place using different agents (programs). A mail user agent (MUA) is a mail client program, such as Evolution, Thunderbird, Kmail, or mail. With an MUA, a user composes a mail message and sends it. Then a mail transfer agent (MTA) transports the messages over the Internet. MTAs are mail servers that use SMTP to send messages across the Internet from one mail server to another, transporting them among subnets. On Fedora, the commonly used MTAs are Postfix and Sendmail. These are mail server daemons that constantly checks for incoming messages from other mail servers and sends outgoing messages to appropriate servers (see Table 6-1). Incoming messages received by a mail server are distributed to a user with mail delivery agents (MDAs). Most Linux systems use procmail as their MDA, taking messages received by the mail server and delivering them to user accounts (see www.procmail.org for more information).

Agent

Description

Sendmail

Sendmail mail transfer agent, supported by the Sendmail consortium
www.sendmail.org

Postfix

Fast, easy-to-configure, and secure mail transfer agent compatible with Sendmail and designed to replace it
www.postfix.org

Exim

MTA based on smail3
www.exim.org

Courier

Courier MTA
http://www.courier-mta.org/imap/s

 Table 6-1: Mail Transfer Agents

For documentation for mail servers on Fedora see the Fedora System Administration Guide | Servers | Mail Servers. It provides an overview of mail services and basic configuration for mail servers such as Postfix and Sendmail.

https://docs.fedoraproject.org/f28/system-administrators-guide/servers/Mail_Servers.html

Mail Transport Agents

On Fedora, you can install and configure either Postfix, Exim, or Sendmail. You can also set up your Linux system to run a POP server. POP servers hold users’ mail until they log in to access their messages, instead of having mail sent to their hosts directly.

Courier is a fast, small, and secure MTA that maintains some compatibility with Sendmail. The Courier software package also includes POP, IMAP, and webmail servers along with mailing list services. It supports extensive authentication methods including shadow passwords, PAM, and LDAP.

Exim is a fast and flexible MTA similar to Sendmail. Developed at the University of Cambridge, it has a very different implementation than Sendmail.

Postfix

Postfix is a fast, secure, and flexible MTA designed to replace Sendmail while maintaining as much compatibility as possible. Written by Wietse Venema and originally released as the IBM Secure Mailer, it is now available under the GNU license (www.postfix.org). Postfix was created with security in mind, treating all incoming mail as potential security risks. Postfix uses many of the same Sendmail directories and files and makes use of Sendmail wrappers, letting Sendmail clients interact seamlessly with Postfix servers. Postfix is also easier than Sendmail to configure, using its own configuration file.

Instead of one large program, Postfix is implemented as a collection of smaller programs, each designed to perform a specific mail-related task. A Postfix master daemon runs continuously and manages the use of the other Postfix daemons, running them only as needed. A bounce daemon handles undeliverable mail, a trivial-rewrite daemon redirects messages, and the showq daemon provides information on the print queues.

postfix.service

[Unit]
Description=Postfix Mail Transport Agent
After=syslog.target network.target
Conflicts=sendmail.service exim.service

[Service]
Type=forking
PIDFile=/var/spool/postfix/pid/master.pid
EnvironmentFile=-/etc/sysconfig/network
PrivateTmp=true
CapabilityBoundingSet=~ CAP_NET_ADMIN CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_MODULE
ProtectSystem=true
ProtectDevices=true
ExecStartPre=-/usr/libexec/postfix/aliasesdb
ExecStartPre=-/usr/libexec/postfix/chroot-update
ExecStart=/usr/sbin/postfix start
ExecReload=/usr/sbin/postfix reload
ExecStop=/usr/sbin/postfix stop

[Install]
WantedBy=multi-user.target

Postfix is managed by systemd using the postfix.service unit file postfix.service shown here. It is started as a standalone daemon by the multi-user target (runlevels 2, 3, 4, and 5) (WantedBy). It conflicts with the sendmail and exim mail servers (Conflicts). It reads runtime configuration from /etc/sysconfig/network (EnvironmentFile). Before it starts it runs the Postfix alias database (ExecStartPre). The /etc/sbin/postfix command is used to start, stop, and reload the server (ExecStart, ExecReload, and ExecStop).

Postfix Commands

Several Postfix commands allow you to manage your server tasks. The sendmail command sends messages. You use mailq to display the status of your mail queues. The newaliases command takes mail aliases listed in the aliases files and stores them in a database file that can be used by Postfix.

The postmap command is used to maintain various database files used by Postfix, such as the alias file for mail aliases and the access file that restricts messages received by the server. You can also implement these database files as SQL databases like MySQL, allowing for easier management. The mysql_table Man page provides detailed information on how to configure SQL database support (check pgsql_table for Postgresql database support). You could also use LDAP instead of SQL (ldap_table).

In addition, Postfix provides lower-level tools, all beginning with the term post, such as the postalias command, which maintains the alias database, and postcat, which displays print queue files.

 Postfix Configuration: main.cf

Postfix configuration is handled by setting parameters in its configuration file, main.cf. The master.cf file holds parameters for running Postfix services, and dynamicmaps.cf file for additional runtime capabilities.

A default /etc/postfix/main.cf file is installed with Postfix, with most of the essential configuration values already set. Parameter names tend to be user-friendly. For example, directory locations are specified by parameters ending in the term directory, such as queue_directory for the location of Postfix queues and daemon_directory for the location of the Postfix daemons. Defaults are already implemented for most parameters. For example, defaults are set for particular resource controls, such as message size, time limits, and the number of allowed messages per queue. You can edit the main.cf file to change the parameter values to meet your own needs. After making any changes, you need only to reload the configuration using the postfix reload command:

postfix reload

Network Parameters

You will most likely need to set several network parameters. To ease this process, Postfix defines parameters that hold key network information, such as myhostname, which holds the hostname of your system, and mydomain, which holds the domain name of your network. For example, myhostname would be set to the host turtle.mytrek.com, whereas mydomain would be just mytrek.com. Parameters like myhostname and mydomain are themselves used as values assigned to other parameters. On Fedora, myhostname should set to the system mail name. In the next example, myhostname and mydomain are set to the host the mail server is running on and its network domain:

myhostname=turtle.mytrek.com
mydomain=mytrek.com

The myorigin parameter specifies the origin address for e-mail sent by the server. On Fedora, this is commented out. You could set to the value of the parameter myhostname, as shown here. Note that a $ precedes the myhostname variable to evaluate it.

myorigin=$myhostname

If you are using a single system directly attached to the Internet, you may want to keep this configuration, labeling mail as being sent by your host. If your system is operating as a gateway for a network, your mail server is sending out mail from different hosts on that network. You may wish to change the origin address to the domain name so that mail is perceived as sent from the domain.

myorigin=$mydomain

You also may need to specify the network interfaces that your mail server receives mail on. The localhost interface is designated by default, using the inet_interfaces parameter.

inet_interfaces = localhost

 The inet_protocols option specifies the IP protocol to use. This can be IPV4, IPV6, or all for both.

inet_protocols = all

Local Networks

The mydestination parameter holds the list of domains that your mail server will receive mail for. By default, these include localhost and your system’s hostname.

mydestination = $myhostname, localhost.$mydomain, localhost

If you want the mail server to receive mail for an entire local network, you need to also specify its domain name. That way, the server can receive mail addressed just to the domain, instead of your specific host.

mydestination = $myhostname, localhost.$mydomain, $mydomain

Also, if your host goes by other hostnames and there are DNS records identifying your host by those names, you need to specify those names as well. For example, your host could also be a web server to which mail could be directed. A host turtle.mytrek.com may also be identified as the website mytrek.com. Both names would have to be listed in the mydestination parameter.

mydestination = $myhostname, localhost.$mydomain, $mydomain www.$mydomain

If your system is a gateway for one or more local networks, you can specify them with the mynetworks parameter. This allows your mail server to relay mail addressed to those networks. Networks are specified using their IP addresses. The relay_domains parameter lets you specify domain addresses of networks for which you can relay messages. By default, this is set to mydestination:

mynetworks=192.168.0.0
relay_domains=$mydestination

Hosts within the local network connected to the Internet by a gateway need to know the identity of the relay host, the mail server. You set this with the relayhost parameter. Also, myorigin should be set to just mydomain. If there is a DNS server identifying the gateway as the mail server, you can just set relayhost to the value of mydomain. If not, then relayhost should be set to the specific hostname of the gateway/mail server. If your local network is not running a DNS server, be sure to set disable_dns_lookups to yes.

relay_host=$mydomain

 Direct Connections

If your system is directly connected to the Internet and you use an ISP (Internet service provider) for receiving mail, you can configure Postfix as a null client to only send mail. Set the relay_host parameter to just your own domain name. Also, in the master.cf file, comment out the SMTP server and local delivery agent entries.

relayhost = $mydomain

 Masquerading

If your mail server is operating on a gateway for a local network and you want to hide the hosts in that network, you can opt to masquerade the local hosts, letting it appear that all mail is coming from the domain in general, instead of a particular host. To set this option, you use the masquerade_domains parameter. In the following example, all mail sent by a local host such as rabbit.mytrek.com will be addressed as coming from mytrek.com. Thus a message sent by the user chris@rabbit.mytrek.com is sent out as coming from chris@mytrek.com:

masquerade_domains = $mydomain

Received mail is not masqueraded by default. This allows Postfix to still deliver received mail to particular hosts. If you want received mail to also be masqueraded, you have to add the envelope_recipients parameter to the list of values assigned to the masquerade_class parameter. In that case, Postfix will no longer be able to deliver received mail.

 Virtual Domains and Virtual Accounts

If your network has implemented virtual domains, you will need to set up a virtual domain table and then specify that table with the virtual_maps option. Setting up a table is a simple matter of listing virtual names and their real addresses in a text file such as /etc/postfix/virtual. Then use the postmap command to create a Postfix table:

postmap /etc/postfix/virtual

In the main.cf file, specify the table with the virtual_maps parameter. Postfix will then use this table to look up virtual domains.

virtual_maps = hash:/etc/postfix/virtual

Note: See the Postfix FAQ at www.postfix.org for detailed information on how to set up Postfix for a gateway, a local workstation, or a host directly connected to the Internet (null server).

Instead of using mail accounts for actual users on a system, you can set up virtual accounts. Virtual accounts can be managed either in standard Postfix text files, in SQL databases, or as LDAP entries. SQL databases are preferred for managing a large number of virtual accounts. For SQL support, you first create tables in a MySQL database for domains (the virtual domains), users (user accounts), and forwarding (aliases). Corresponding virtual domain configuration files will list information like the database, tables, and host to use, such as a mysql_virt.cf for SQL database access and mysql_users.cf for accessing the user table. Check the documentation at www.postfix.org for detailed information.

 Postfix Greylisting Policy Server

Postfix also supports greylisting with the Postfix Greylisting Policy Server (postgrey package). Greylisting blocks spammers based on their mailing methods rather than content, relying on the fact that spammers will not attempt retries if rejected (www.greylisting.org). Messages from new previously unknown sources are rejected, whereupon a valid MTA will retry, whereas a spammer will not. To support the Greylisting Policy Server, Postfix is configured to delegate Policy access to a server. In the /etc/postfix directory you can use the postgrey_whitelist files to exclude email addresses from greylisting. The Greylisting Policy Server is run as a standalone server, using its own startup script. The postgrey Man page provides detailed information about the server's options.

For more heavy duty work, you can use the SQL Postfix Greylisting Policy Server (sqlgrey package). This server uses an SQL database backend for processing greylisting tasks. See https://sqlgrey.sourceforge.net for more details.

 Controlling User and Host Access

With an access file, you can control access by certain users, hosts, and domains. The access file works much like the one used for Sendmail. Entries are made in a text file beginning with the user, host, or domain name or address, followed by an action to take. A user, host, or domain can be accepted, rejected with no message, or rejected with a message. Once entries are made, they can be installed in a Postfix database file with the postmap command:

postmap /etc/postfix/access

You can then use the access file in various Postfix operations to control clients, recipients, and senders.

Access can also be controlled by use of the Mail Abuse Prevention System (MAPS), which provides the RBL+ service, a collection of mail address DNS-based databases. These databases, like the Realtime Blackhole List (RBL), list mail addresses that are known be used by mail abusers. A domain or host is matched against a list maintained by the service, which can be accessed on a local server or directly from an online site. Various Postfix operations let you use MAPS databases to control access by clients, recipients, or senders.

 Header and Body Checks

With the header_checks parameter, you can specify a Postfix table where you can list criteria for rejecting messages. Check the /etc/postfix/header_checks file for details. The criteria are patterns that can match message headers. You can have matching messages rejected, rejected with a reply, simply deleted, or logged with a warning. You have the option of taking several actions, including REJECT, DISCARD, WARN, HOLD, and IGNORE.

header_checks = regexp:/etc/postfix/header_checks

The database, in this case, /etc/postfix/header_checks, will have lines, each with a regular expression and a corresponding action. The regular expression can either be a standard regular expression as denoted by regexp in the header_checks parameter or conform to a Perl Compatible Regular Expression, prece.

The body_checks parameter lets you check the body of text messages, line by line, using regular expressions and actions like those used for header_checks in an /etc/postfix/body_checks file.

 Controlling Client, Senders, and Recipients

With the smtpd_client_restrictions parameter, you can restrict access to the mail server by certain clients. Restrictions you can apply include reject_unknown_client_hostname, which will reject any clients with unresolved addresses; permit_mynetworks, which allows access by any clients defined by mynetworks; and check_client_access, which will check an access database to see if a client should be accepted or rejected. The reject_rbl_client and reject_rhsbl_client parameters will reject clients from specified domains.

smtpd_client_restrictions = permit_mynetworks, \
             reject_unknown_client_hostname, check_client_access

The reject_rbl_client restriction rejects domain addresses according to a specified MAPS service. The site can be an online site or a local one set up to provide the service. The reject_rhsbl_client restriction rejects host addresses.

smtpd_client_restrictions = reject_rbl_client relays.mail-abuse.org

To implement restrictions from an access file, you can use the hash directive and the name of the file.

smtpd_client_restrictions = hash:/etc/postfix/access

The corresponding smtpd_sender_restrictions parameter works much the same way as its client counterpart but controls access from specific senders. It has many of the same restrictions but adds reject_non_fqdn_sender, which will reject any mail header without a fully qualified domain name, and reject_sender_login_mismatch, which will require sender verification. The reject_rhsbl_sender restriction rejects domain addresses according to a specified MAPS service.

The smtpd_recipient_restrictions parameter will restrict the recipients the server will accept mail for. Restrictions include permit_auth_destination, which allows authorized messages, and reject_unauth_destination, which rejects unauthorized messages. The check_recipient_access restriction will check local networks for a recipient address. The reject_unknown_recipient_domain restriction rejects recipient addresses with no DNS entry. The reject_rhsbl_recipient restriction rejects domain addresses according to a specified MAPS service.

You can further refine restrictions with parameters such as smtpd_helo_restrictions, which requires a HELO command from a client. Restriction parameters include reject_invalid_helo_hostname, which checks for faulty syntax, reject_unknown_helo_hostname, for hosts with no DNS entry, and reject_non_fqdn_helo_hostname for hosts whose names are not fully qualified. The strict_rfc821_envelopes parameter will implement strict envelope protocol compliance.

Sendmail

Sendmail operates as a server to both receive and send mail messages. Sendmail listens for any mail messages received from other hosts and addressed to users on the network hosts it serves. At the same time, Sendmail handles messages users are sending out to remote users, determining what hosts to send them to. You can learn more about Sendmail at www.sendmail.org, including online documentation and current software packages. The Sendmail newsgroup is comp.mail.sendmail. You can also obtain a commercial version from www.sendmail.com.

The domain name server for your network designates the host that runs the Sendmail server. This is your mail host. Messages are sent to this host, whose Sendmail server then sends the message to the appropriate user and its host. In your domain name server configuration file, the mail host entry is specified with an MX entry. To print the mail queue of messages for future delivery, you can use mailq (or sendmail -v -q). This runs Sendmail with instructions to print the mail queue.

The Sendmail software package contains several utilities for managing your Sendmail server. These include mailq, which displays the queue of outgoing messages; mailstats, which shows statistics on mail server use; hoststat, which provides the stats of remote hosts that have connected with the mail server; and praliases, which prints out the mail aliases listed in the /etc/aliases file. Some, like mailq and hoststat, simply invoke Sendmail with certain options. Others, like mailstats and praliases, are separate programs.

Sendmail maintains all configuration and database files in the /etc/mail directory. Here you will find the Sendmail macro configuration file, sendmail.mc, as well as several database files (see Table 6-2). Specialized files provide support for certain features such as access, which lets you control access by different hosts and networks to your mail server, and virtusertable, which lets you designate virtual hosts. These files have both text and database versions. The database version ends with the extension .db and is the file actually used by Sendmail. You would make your entries in the text version and then effect the changes by generating a corresponding database version. Database versions are generated using the makemap command with the hash option and a redirection operation for the text and database file. For example, to deny access to a particular host, you would place the appropriate entry for it in the /etc/mail/access file, editing the file using any text word processor. Then, to generate the /etc/mail/access.db version of the access file, you would change to the /etc/mail directory and use the following command:

cd /etc/mail
makemap hash access < access

To regenerate all the database files, just use the make command in the /etc/mail directory:

make

File

Description

/etc/mail/sendmail.cf

Sendmail configuration file

/etc/mail/sendmail.mc

Sendmail M4 macro configuration file

/etc/mail/submit.cf

Sendmail configuration file for mail submission mode where Sendmail does not run as a server but merely submits mail.

/etc/mail/submit.mc

Sendmail M4 macro configuration file for Sendmail mail submission mode.

/etc/aliases

Sendmail aliases file for mailing lists

/etc/aliases.db

Sendmail aliases database file generated by the newaliases command using the aliases file

/etc/mail/access

Sendmail access text file. Access control for screening or relaying messages from different hosts, networks, or users. Used to generate the access.db file

/etc/mail/access.db

Sendmail access database file. Generated from the access text file

/etc/mail/local-host-names

Sendmail local hosts file for multiple hosts using the same mail server (formerly sendmail.cw)

/etc/mail/trusted-users

Sendmail trusted users file (formerly sendmail.ct)

/etc/mail/statistics

Sendmail statistics file (formerly sendmail.st)

/etc/mail/virtusertable

Sendmail virtual user table text file. Maps user virtual domain addresses, allowing virtual domains to be hosted on one system. Make entries in this file and then use it to generate the virtusertable.db file

/etc/mail/virtusertable.db

Sendmail virtual user table database generated from the virtusertable file

/etc/mail/mailertable

Sendmail mailer table text file, used to override routing for your domains

/etc/mail/mailertable.db

Sendmail mailer table database file, generated from the mailertable file

/etc/mail/userdb

Sendmail user database file

/etc/mail/domaintable

Sendmail domaintable file, maps a domain name to another domain name

/etc/mail/domaintable.db

Sendmail domaintable database file, generated from the domaintable file

/var/spool/mail

Incoming mail

/var/spool/mqueue

Outgoing mail

/var/spool/maillog

Mail log file

Table 6-2: Sendmail Files and Directories

Certain files and directories are used to manage the mail received and sent. Incoming mail is usually kept in the /var/spool/mail directory, and outgoing messages are held in the /var/spool/mqueue directory, with subdirectories for different users. Monitoring and error messages are logged in the /var/log/maillog file.

Sendmail is managed by systemd using the unit file sendmail.service shown here.  It is started as a standalone daemon with the multi-user target (runlevels 2, 3, 4, and 5) (WantedBy). It conflicts with the postfix and exim mail servers (Conflicts). It reads network configuration from /etc/sysconfig/sendmail (EnvironmentFile) and sets the SENDMAIL_OPTS environment variable (Environment). Before it starts, it runs the Sendmail make operation, etc/mail/make (ExecStartPre). The /etc/sbin/sendmail command is used to start (ExecStart).

sendmail.service

[Unit]
Description=Sendmail Mail Transport Agent
After=syslog.target network.target
Conflicts=postfix.service exim.service
Wants=sm-client.service
StartLimitIntervalSec=0

[Service]
Type=forking
PIDFile=/run/sendmail.pid
Environment=SENDMAIL_OPTS=-q1h
EnvironmentFile=-/etc/sysconfig/sendmail
ExecStartPre=-/etc/mail/make
ExecStartPre=-/etc/mail/make aliases
ExecStart=/usr/sbin/sendmail -bd $SENDMAIL_OPTS $SENDMAIL_OPTARG

[Install]
WantedBy=multi-user.target
Also=sm-client.service

Note: If your mail server services several hosts, you will need to enter them in the /etc/mail/local-host-names file.

Aliases and LDAP

Sendmail also supports the Lightweight Directory Access Protocol (LDAP). LDAP enables the use of a separate server to manage Sendmail queries about user mail addresses. Instead of maintaining aliases and virtusertable files on different servers, Sendmail uses LDAP support to simply use one centralized LDAP server to locate recipients. Mail addresses are looked up in the LDAP server, instead of having to search several aliases and virtusertable files on different servers. LDAP also provides secure authentication of users, allowing controlled access to mail accounts. The following example enables LDAP support on Sendmail in the sendmail.mc file:

FEATURE('ldap_routing')dnl
LDAPROUTE_DOMAIN('mytrek.com')dnl

Alternatively, Sendmail still supports the use of aliases, for either sent or received mail. It checks an aliases database file called aliases.db that holds alias names and their associated e-mail addresses. This is often used for administrator mail, where mail may be sent to the system’s root user and then redirected to the mail address of the actual system administrator. You can also alias host addresses, enabling you to address hosts on your network using only their aliases. Alias entries are kept in the /etc/aliases file, which consists of one-line alias records associating aliases with user addresses. You can edit this file to add new entries or to change old ones. They are then stored for lookup in the aliases.db file using the command newaliases, which runs Sendmail with instructions to update the aliases.db file.

Aliases allow you to give different names for an e-mail address or collection of e-mail addresses. One of its most useful features is to create a mailing list of users. Mail addressed to an alias will be sent to the user or list of users associated with the alias. An alias entry consists of an alias name terminated by a colon and followed by a username or a comma-separated list of users. For example, to alias filmcritic with the user george@rabbit.mytrek.com, you would use the following entry:

filmcritic:   george@rabbit.mytrek.com

To alias singers with the local users aleina and larisa, you would use

singers:     aleina, larisa

You can also use aliases as the target addresses, in which case they will expand to their respective user addresses. For example, the performers alias will expand through the filmcritic and singers aliases to the users george@rabbit.mytrek.com, aleina, and larisa:

performers:     filmcritic, singers

Once you have made your entries in the /etc/mail/aliases file, you need to generate a database version using the newaliases command:

newaliases

Note: Sendmail now supports a mail submission mode. In this mode, Sendmail does not run as a server along with the corresponding root privileges. Instead, it merely submits mail. In this mode, Sendmail can be invoked directly by Email clients to send mail.  The mail submission mode uses the /etc/mail/submit.cf configuration file which can be configured using macros in the /etc/mail.submit.mc file.

Sendmail Configuration

The main Sendmail configuration file is sendmail.cf, located in the /etc directory. This file consists of a sometimes lengthy list of mail definitions that set general options, designate MTAs, and define the address rewrite rules. A series of options set features, such as the maximum size of mail messages or the name of host files. The MTAs are those mailers through which Sendmail routes messages. The rewrite rules “rewrite” a mail address to route through the appropriate Internet connections to its destination (these rules can be complex). Check the Sendmail HOW-TO and the online documentation for a detailed explanation.

The sendmail.cf definitions can be complex and confusing. To simplify the configuration process, Sendmail supports the use of macros you can use to generate the sendmail.cf file using the M4 preprocessor (this requires the installation of the sendmail-cf package). Macros are placed in the /etc/mail/sendmail.mc file. Here, you can use macros to designate the definitions and features you want for Sendmail, and then the macros are used to generate the appropriate definitions and rewrite rules in the sendmail.cf file. As part of the Sendmail package, several specialized versions of the sendmail.mc file are made available in the /usr/share/sendmail-cf directory. These begin with a system name and have the suffix .mc. On many distributions, a specialized version tailored to your distribution is already installed as your /etc/mail/sendmail.mc file.

Once you configure your sendmail.mc file, you use the following command to generate a sendmail.cf file (be sure first to back up your original sendmail.cf file). You can rename the sendmail.mc file to reflect the specific configuration. You can have as many different .mc files as you want and use them to implement different configurations. On Red Hat and Fedora you can use the following command in the /etc/mail directory:

sudo make -C /etc/mail

Alternatively, you can use the original m4 macro command:

sudo m4 sendmail.mc > /etc/mail/sendmail.cf

You will then need to restart the Sendmail server to make the configuration effective:

sudo systemctl restart sendmail

In the sendmail.mc file, you configure different aspects of Sendmail using either a define command to set the value of Sendmail variables or a Sendmail macro that has already been defined to set a particular Sendmail feature. For example, to assign the PROCMAIL_PATH variable to the directory /usr/bin/procmail, you would use the following:

define(‘PROCMAIL_MAILER_PATH',’/usr/bin/procmail')

Similarly, if there are variables that you do not want defined, you can remove them with the undefine command:

undefine('UUCP_RELAY')

To specify the type of operating system that your Sendmail server is running on, you would use the OSTYPE Sendmail macro. The following example specifies the Linux operating system:

OSTYPE('linux')

The MAILER macro specifies the mail delivery agents (MDAs) to be used. You may have more than one. Usually, you will need a mail delivery agent such as procmail for delivering mail to hosts on your network. In addition, Sendmail in effect operates as an MDA to receive messages from hosts in its local network, which it will then send out to the larger network.

MAILER(procmail)
MAILER(smtp)

Sendmail also supports an extensive number of features that you need to explicitly turn on. You can do this with the Sendmail FEATURE macro. See Table 6-3 for a list of commonly used Sendmail features. The following example turns on the redirect feature, which is used to inform a sender that a recipient is now at a different address:

FEATURE(redirect)

In addition, you can set certain configuration options. These are variables beginning with the prefix conf that you can set and assign values to using the define command. There are an extensive number of configuration options, most of which you will not need to change. The following example defines the confAUTO_REBUILD configuration option, which will automatically rebuild the aliases database if needed:

define('confAUTO_REBUILD')

Feature

Description

use_cw_file

Checks for hosts served by the mail server /etc/mail/local-host-names file.

use_ct_file

Reads a list of users from the /etc/trusted-users file. These are trusted users that can change the sender name for their messages.

redirect

Rejects all mail addressed to "address.REDIRECT", providing a forwarding address is placed in the /etc/aliases file.

mailertable

Uses a mailer table file, /etc/mail/mailertable, to override routing for particular domains.

domaintable

Uses a domain table file, /etc/mail/domaintable, to map one domain to another. Useful if you change your domain name.

allmasquerade

Causes recipient addresses to also masquerade as being from the masquerade host.

masquerade_entire_domain

Masquerades all hosts within the domain specified in MASQUERADE_AS.

masquerade_envelope

Masquerades envelope sender and recipient along with headers.

virtusertable

For virtual hosts, maps virtual addresses to real addresses.

nullclient

Turns a Sendmail server into a null client, which simply forwards mail messages to a central mail server for processing.

local_procmail

Uses procmail as the local mailer.

smrsh

Uses the Sendmail Restricted Shell (smrsh) for mailing.

promiscuous_relay

Allows you to relay mail, allowing mail to be received from outside your domain and sent on to hosts outside your domain.

relay_entire_domain

Allows any host in your domain to relay mail (default limits this to hosts in the access database).

relay_hosts_only

Checks for relay permission for particular hosts instead of domains.

accept_unqualified_senders

Allows sender e-mail addresses to be single usernames instead of just fully qualified names that include domain names.

accept_unresolvable_domains

Allows Sendmail to accept unresolvable domain names. Useful for those users in a local network blocked by a firewall from the full DNS namespace. By default, Sendmail requires domains in addresses to be resolvable with DNS.

access_db

Accepts or rejects mail from domains and hosts in the access database.

blacklist_recipients

Blocks mail to certain users, such as those that should never receive mail—like the users nobody and host.

dnsbl

Rejects hosts in the Realtime Blackhole List. Managed by MAPS (Mail Abuse Prevention System LLC) and designed to limit transport of unwanted mass e-mail .

ldap_routing

Enables LDAP use.

Table 6-3: Sendmail Features

Certain macros and types of macros need to be placed in the sendmail.mc file in a particular sequence as shown here. Notice that MAILER is toward the end and OSTYPE at the beginning. Local macro definitions (define) and FEATURE entries follow the OSTYPE and DOMAIN entries:

VERSIONID
OSTYPE
DOMAIN
define
FEATURE
local macro definitions
MAILER
LOCAL_RULE_*
LOCAL_RULESETS

The local macro and configuration option definitions that affect a particular feature need to be entered before the FEATURE entry. For example, the redirect feature uses the aliases file. Any local definition of the aliases file needs to be entered before the redirect feature.

define('ALIAS_FILE','/etc/aliases')
FEATURE(redirect)

You need to be careful how you enter comments into a sendmail.mc file. This file is read as a stream of macros, ignoring all white spaces, including newlines. No special comment characters are looked for. Instead, you have to simulate comment indicators using the dnl or divert commands. The dnl command instructs that all characters following that dnl command up to and including the next newline are to be ignored. If you place a dnl command at the beginning of a text line in the sendmail.mc file, it has the effect of turning that line into a comment, ignoring everything on that line—including its newline. Even empty lines will require a dnl entry to ignore the newline character:

dnl you will have to /etc/mail/sendmail.cf by running this the m4
dnl macro config through preprocessor:
dnl

Alternatively, you can use the divert command. The divert command will ignore all data until another divert command is reached:

divert(-1)
This is the macro config file used to generate
the /etc/mail/sendmail.cf file. If you modify the file regenerate
you will have to regenerate /etc/mail/sendmail.cf by running the m4
macro
divert(0)

For Sendmail to work at all, it requires only that the OSTYPE and MAILERS macros be defined, along with any needed features and options. A very simple Sendmail file is shown here:

mysendmail.mc

dnl My sendmail.mc file
OSTYPE('linux')
define('PROCMAIL_MAILER_PATH','/usr/bin/procmail')
FEATURE(redirect)
MAILER(procmail)
MAILER(smtp)

A sendmail.mc file usually contains many more entries, particularly for parameters and features. Check the /etc/mail/sendmail.mc file on your Red Hat or Fedora system to see the standard default entries for Sendmail.

Sendmail Masquerading

For a mail server that is relaying messages from local hosts to the Internet, you may want to masquerade the source of the messages. In large networks that have their own mail servers connected to the Internet, Sendmail masquerading can make messages sent by local hosts appear to be sent by the mail server. Their host address will be replaced by the mail server’s address. Returned mail can then be sent to the mail server and held in POP or IMAP server mailboxes that can be later accessed by users on the local hosts. Also, entries in the server’s virtual user table could forward mail to corresponding users in local hosts.

Masquerading is often used to mask local hosts with a domain name. Any subdomains can also be masqueraded. This method can be applied to situations where an ISP or your network administrator has assigned your network its own domain name. You can then mask all mail messages as coming from your domain name instead of from particular hosts or from any subdomains you may have. For example, if a network’s official domain name is mytrek.com, all messages from the hosts in the mytrek.com network, such as rabbit.mytrek.com and turtle.mytrek.com, could be masqueraded to appear as just coming from mytrek.com. Should the mytrek.com network have a subnetwork whose domain is mybeach.com, any messages from mybeach.com could also be masqueraded as coming from mytrek.com.

Masquerading is turned on with the MASQUERADE_AS command. This takes as its argument the name you want to masquerade your mail as. Normally, the name used is just the domain name, without the mail host. In the following example, the mail is masqueraded as simply mytrek.com. Mail sent from a local host like turtle.mytrek.com will appear to be sent by just mytrek.com:

MASQUERADE_AS('mytrek.com')dnl

You will also have to specify the hosts and domains on your local network that your Sendmail server should masquerade. If you have decided to masquerade all the hosts in your local network, you just need to set the masquerade_entire_domain feature, as in

FEATURE('masquerade_entire_domain')dnl

If instead, you want to masquerade particular hosts or your domain has several subdomains that you want masqueraded, you list them in the MASQUERADE_DOMAIN entry. You can list either particular hosts or entire domains. For example, given a local network with the local hosts turtle.mytrek.com and rabbit.mytrek.com, you can list them with the MASQUERADE_DOMAIN to have them masqueraded. The domain they are masqueraded as is specified in the MASQUERADE_AS entry.

MASQUERADE_DOMAIN('turtle.mytrek.com rabbit.mytrek.com')dnl

If you want to masquerade all the hosts in your local network, you can simply list your local network’s domain name. If your local network also supports several subdomains, you can list those as well to masquerade them. For example, to masquerade all the hosts in the mybeach.com domain, you would use the following entry:

MASQUERADE_DOMAIN('mytrek.com mybeach.com')dnl

If you have a long list of domains or hosts, or if you want to be able to easily change those that should be masqueraded, you can place them in a file to be read by Sendmail. Specify the file with the MASQUERADE_DOMAIN_FILE command:

MASQUERADE_DOMAIN_FILE('mydomains')dnl

If you just want to masquerade all the hosts in your local domain, you use the masquerade_entire_domain feature:

FEATURE(masquerade_entire_domain)dnl

A common configuration for a local network would specify the domain name in the MASQUERADE_AS entry and in the MASQUERADE_DOMAIN entry. Using the example myisp.com for the domain, the entries would look like this:

MASQUERADE_AS('mytrek.com')dnl
FEATURE(masquerade_entire_domain)dnl

If you wanted to masquerade as an ISP’s mail domain, you would use the ISP’s domain in the MASQUERADE_AS entry as shown here:

MASQUERADE_AS('myisp.com')dnl
MASQUERADE_DOMAIN('mytrek.com')dnl

When mail is received from the outside bearing just the address mytrek.com, your network needs to know what host to send it to. This is the host designated as the mail server for the mytrek.com network. This information is provided by a mail exchange record (MX) in your DNS configuration that will specify that mail sent to mytrek.com will be handled by the mail server—in this case, turtle.mytrek.com:

mytrek.com.  IN    MX     0     turtle.mytrek.com.

You further have to be sure that MX relaying is enabled with the relay_based_on_MX feature:

FEATURE(relay_based_on_MX)dnl

All messages will appear to originate from the mail server’s host. For example, if your Sendmail mail server is running on turtle.mytrek.com, mail sent from a local host called rabbit.mytrek.com will appear to have been sent from turtle.mytrek.com.

You can also masquerade recipient addresses so that mail sent to users on your local host will be sent instead to the masqueraded address. Use the allmasquerade feature to enable recipient masquerading:

FEATURE(allmasquerade)dnl

Configuring Mail Servers and Mail Clients

Sendmail can be used either as a mail server, handling mail for various hosts on a network, or as a mail client, managing mail for local users on a particular host. In a simple network configuration, you would have each host running Sendmail in a client configuration, and one host operating as a mail server, relaying mail for the network hosts. For a local network connected to the Internet, your local hosts would run Sendmail in a client configuration, and your gateway would run Sendmail in a server configuration (though the mail server would not have to necessarily run on the gateway). The mail server would relay messages from the local network hosts out to the Internet. The mail server could also be used to block unwanted access from outside hosts, such as those sending spam mail. A basic client or server Sendmail configuration involves just a few features in the /etc/mail/sendmail.mc file. The default Fedora configuration installed on your system allows use on a single host, managing messages between users on that host. To enable client and server use, you will need to make changes to the /etc/mail/sendmail.mc file.

 Configuring Sendmail for a Simple Network Configuration

Fedora initially configures Sendmail to work only on the system it is running on, localhost. To use Sendmail to send messages to other hosts on a local network, you need to change and add settings in the sendmail.mc and /etc/mail/access files. A simple network configuration would have Sendmail running on each host, handling both mail sent between users on that host and mail to and from users on other hosts. For each Sendmail server configuration, you would make the changes described in the following section on simple local network configuration.

For messages sent between hosts on your network, you only need to run the Sendmail server on each, making a few changes to their Sendmail configurations. The Sendmail server on one of your hosts can be configured to handle the task of relaying messages between hosts. Using the network example described earlier, the hosts turtle, rabbit, and lizard will be running their own Sendmail servers. The Sendmail server on the turtle host will be configured to relay messages between all the host, itself included.

On each host on your network, edit the /etc/mail/sendmail.mc file and make the following changes. Comment out the DAEMON_OPTIONS line in the default sendmail.mc file by placing a dnl word in front of it, as shown here. Removing this feature will allow you to receive messages over your local network. This entry is restricting Sendmail to the localhost (127.0.0.1):

dnl DAEMON_OPTIONS('Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

In the sendmail.mc file located on the host that you want to have handle the relaying of messages, you need to also add the following line:

FEATURE(relay_entire_domain)dnl

Run the m4 operation to install the changed configuration and then restart the server with the service operation, as described earlier.

You can now e-mail messages from one user to another across your network. For example, george@turtle.mytrek.com can now e-mail a message to larisa@rabbit.mytrek.com. The local Sendmail servers will take care of sending and delivering mail both to users within their hosts and those located on other network hosts.

Configuring Sendmail for a Centralized Mail Server

Alternatively, you could set up a central mail server to handle all the mail on your network. Mail clients on various hosts could send their messages to the central mail server, which would then relay them out to the larger network or Internet. Mail could then be received at the central mail server, where clients could later retrieve it. There are several ways to set up a central mail server. One of the simplest is to run a central mail server on your gateway host, and then have null client versions of the Sendmail server running on local hosts. Any mail sent from local hosts would be automatically forwarded to the central mail server. Received mail could only be delivered to the central server, usually to a POP or IMAP server also running on the central server’s host. Users could then access the POP server to retrieve their mail.

For a centralized configuration, it would make sense to treat users as having their network domain as their address, rather than separate hosts in their network. Thus the user cece on rabbit.mytrek.com would use the mail address cece@mytrek.com, not cece@rabbit.mytrek.com. Users could have the same name as those on their respective hosts, but corresponding users would be set up on the gateway host to handle received mail managed by the POP or IMAP servers.

An effective simple mail server would involve several components:

A central mail server running on the gateway host

Each client running Sendmail as a null client

Masquerading all mail to use the domain address only, not host addresses

A POP or IMAP server running on the gateway host to handle received mail

Configuring a Workstation with Direct ISP Connection

If you are running a Linux system that is not part of a network but does have a direct connection to the Internet through an ISP (Internet service provider), you could simply use the ISP mail servers for sending and receiving mail. Normally, you would have an SMTP mail server for outgoing mail and a POP server for incoming mail. However, you can also configure Sendmail to interface with your ISP.

Be sure to first comment out the DAEMON_OPTIONS option as shown in the previous sections.

Normally, your ISP will provide a mail server that will handle mail for its hosts. To make use of the ISP mail server, you can define it with the SMART_HOST option. Mail will be sent through the ISP mail server. SMART_HOST has the format type:hostname, where type is the kind of mail server used, usually SMTP. The default is relay. Define the SMART_HOST option to use your ISP to send and receive mail:

define ('SMART_HOST', 'smtp:mail.my-isp.com')dnl

The SMART_HOST option is used to indicate a specific remote mail server that you want to have handled the relaying of your network messages. It can be an ISP mail server, as well as any mail server in a larger network.

For a dial-up connection over a modem, you can use various configuration options to control your connection. The confMESSAGE_TIMEOUT option lets you control how long mail can remain on the output queue, letting you keep mail until you are ready to dial in and send it. Setting the confDELIVERY_MODE option to queueonly lets you send mail only when you are ready.

The Mailer Table

The mailer table lets you route messages addressed to a specified host or domain to a particular mail server. You can use the mailer table to have mail addressed to a virtual domain routed to the mail server for your network. To reference an entire domain, prefix the domain name with a period. The host to which the mail is routed is prefixed by the mailer used, usually, smtp for Sendmail. The following entry will route mail addressed to .mybeach.com to the mail server turtle.mytrek.com:

.mybeach.com       smtp:turtle.mytrek.com

Entries are placed in the /etc/mail/mailertable file. Once you have made your entries, generate the mailertable.db database file with the make command:

make mailertable

Virtual Domains: virtusertable

You can define virtual domains for your network. These virtual domains are mapped to one or more real domains by your DNS server. You can receive messages with mail addresses for users on your virtual domains. In this case, you need to map these addresses to users on your real domain so that the mail can be delivered to an existing location. This mapping is carried out by the virtual user table called /etc/mail/virtusertable. The virtual user table lets you map mail addresses for virtual domains to users on real domains. Once you have made your entries, generate the virtusertable.db database file with the make command:

make virtusertable

Security

For security, Sendmail lets you screen specific messages as well as provide authentication and encryption for Sendmail transmissions. Sendmail incorporates support for the Secure Sockets Layer (SSL) and the Simple Authentication and Security Layer (SASL). Support for SSL goes by the Sendmail command STARTTLS, which stands for “start transport layer security.” SSL provides authentication, encryption, and integrity checks for Sendmail operations. OpenSSL must first be installed to allow the use of SSL encryption and authentication methods.

The SASL is implemented by the AUTH command and is referred to as SMTP AUTH. SASL provides authentication for mail users and servers. It can make use of already-installed Kerberos services to provide authentication.

Sendmail also provides you with the capability of screening out messages from a specific domain, host, IP, and user addresses. Rules to perform such screening are kept in the /etc/mail/access file. You can edit this file and add your own rules. A rule consists of an address followed by an action to take. (The actions supported are listed in Table 6-4.) For example, to remove all messages from the myannoyingad.com domain, you would enter

myannoyingad.com DISCARD

Action

Description

OK

Accepts message even if other rules would reject (exception to the rules).

DISCARD

Discards the message completely.

REJECT

Rejects the message, sending a rejection notice to the sender.

RELAY

Relays messages for specified domain.

SMTP-code message

Code and message to be sent to the sender.

Tags

Description

Connect:address

Tags connection access

To:recipient

Tags messages sent to recipient

From:sender

Tags messages received by sender

Table 6-4: Access Actions

The next example rejects any message from larisa@turtle.mycar.com and sends a notice of the rejection:

larisa@turtle.mycar.com REJECT

You can also specify an error message to return, as shown here:

cecelia@rabbit.mytrek.com    ERROR:”Retired yesterday”

To send an error message to spammers, you could include a message as shown here. The first number is an error code:

cyberspammer.com     ERROR:"550 We don't accept mail from spammers"

An /etc/mail/access file with the previous entries would look like the following:

myannoyingad.com           DISCARD
larisa@turtle.mycar.com    REJECT
cecelia@rabbit.mytrek.com  ERROR:"Retired yesterday"
cyberspammer.com           ERROR:"550 We don't accept mail from spammers"

Sendmail actually reads the access rules from a database file called access.db, also located in the /etc/mail directory. To implement your rules, you have to regenerate the access.db file using the access file. You can do this with the make command using access as the argument, as shown here:

make access

Sendmail then has to be restarted to read the new access.db file.

The use of the access file is enabled in the sendmail.mc file with the access_db feature:

FEATURE('access_db')dnl

The access file will deny mail received from the listed addresses. However, you can also reject any mail sent to them. Additionally, you can also receive mail for certain hosts on your network. You do this by enabling the blacklist_recipients option in the sendmail.mc file. This option governs recipients, whereas access normally governs senders. Those addresses listed will not be able to receive any mail. This feature is also used for certain administrative users that should never receive mail, such as nobody (the guest user) or ftp (the FTP user):

FEATURE('blacklist_recipients')dnl

The following example will not allow mail to be sent to cyberspammer.com (a recipient), nor can mail be received for justin@lizard.mytrek.com, secretproject@rabbit.mytrek.com, or mysurfboard.com:

mysurfboard.com                  ERROR:"Domain does not exist"
justin@lizard.mytrek.com         "Moved to Hawaii"
secretproject@rabbit.mytrek.com  REJECT
cyberspammer.com                 REJECT

For more refined directional control you can use tags that specify the connection, from, and to operations. You could reject messages received from an address but allow messages to still be sent to that address. Tagged entries are checked first and given priority. There are three tags: Connect, To, and From. The Connect tag allows connections, such as relays. The From tag is used for messages received from a particular sender, and the To tag used for messages that can be sent to a recipient. The following example allows messages to be received from justin but does not allow messages to be sent to larisa.

From:justin@lizard.mytrek.com        OK
To:larisa@turtle.mycar.com           REJECT

On Fedora, relay access is granted to users on localhost (local machine), as shown here.

Connect:localhost.localdomain   RELAY
Connect:localhost               RELAY
Connect:127.0.0.1               RELAY

If your system is being used as a mail server for a network and you have not enabled the relay_entire_domain feature, you will need to allow access by other hosts on your network. In the access file, you can place a RELAY rule for your network. The RELAY rule will let other hosts use your mail server to send messages out to other hosts. This is normally done for a gateway host that needs to relay messages from a local network out to the Internet. The following example allows access from the mytrek.com network:

Connect:mytrek.com      RELAY

For a specific host, place an entry for it in the access file as shown here:

Connect:rabbit.mytrek.com    RELAY

To further secure Sendmail, you should disable the use of VRFY. This option allows remote users to try to verify the existence of a user address. This can be used to guess valid users on your system. This option is disabled with the noverify feature:

FEATURE('noverify')dnl

Another potential security breach is the EXPN option, which expands mailing lists and aliases to their actual addresses. Use the noexpn feature to turn it off:

FEATURE('noexpn')dnl

By default, Sendmail will refuse mail from any domain that cannot be resolved. You can override this restriction with the accept_unresolvable_domains feature. Sendmail will also reject mail whose addresses do not have fully qualified domain names. You can override this feature with accept_unqualified_senders.

POP and IMAP Server: Dovecot

The protocols Internet Mail Access Protocol (IMAP) and Post Office Protocol (POP) allow a remote server to hold mail for users who can then fetch their mail from it when they are ready. Unlike procmail, which delivers mail messages directly to a user account on a Linux system, the IMAP and POP protocols hold mail until a user accesses an account on the IMAP or POP server. The servers then transfer any received messages to the user’s local mailbox. Such servers are often used by ISPs to provide Internet mail services for users. Instead of being sent directly to a user’s machine, the mail resides on the IMAP or POP server until it’s retrieved. Fedora can install Dovecot as its IMAP and POP servers. Other popular IMAP and POP servers available are Qpopper, the Qmail POP server, the Washington University POP and IMAP servers, and the Courier POP and IMAP servers.

You can access the POP server from different hosts; however, when you do, all the messages are transferred to that host. They are not kept on the POP server (though you can set an option to keep them). The POP server simply forwards your messages on the requesting host. When you access your messages from a certain computer, they will be transferred to that computer and erased from the POP server. If you access your POP server again from a different computer, those previous messages will be gone.

The Internet Mail Access Protocol (IMAP) allows a remote server to hold mail for users who can then log in to access their mail. Unlike the POP servers, IMAP servers retain user mail messages. Users can even save their mail on the IMAP mail server. This has the advantage of keeping a user’s mail in one centralized location accessible anywhere on the network. Users can log in to the mail server from any host on the network and read, send, and save their mail.

Unlike POP, IMAP allows users to set up multiple folders on their mail server in which they can organize their mail. IMAP also supports the use of shared folders to which several users can access mail on a given topic.

Dovecot

Dovecot is a combination IMAP and POP server, as well as an LDA (Local Delivery Agent). Using its own indexing methods, Dovecot is able to handle a great deal of e-mail traffic. It features support for SSL, along with numerous authentication methods. Password database support includes shadow passwords, LDAP, PAM, and MySQL. Dovecot can function as a local delivery agent for the major mail servers, including Postfix, Exim, and Sendmail. For detailed configuration information check https://wiki.dovecot.org/. For information about the Dovecot LDA check https://wiki.dovecot.org/LDA.

Dovecot is managed by systemd using the dovecot.service unit file. You can start and stop dovecot manually with the systemctl command.

The dovecot configuration files are located in the /etc/dovecot directory. Basic configuration options are placed in /etc/dovecot/dovecot.conf and specific configurations are held in configuration files located in the conf.d subdirectory (/etc/dovecot/conf.d). These files are read in by the dovecot.conf file with the following include operation.

!include conf.d/*.conf

The configuration is organized into several files in the conf.d subdirectory such as 10-logging.conf for Logging, 10-ssl.conf for SSL settings, 10-master.conf for Login processes, 10-mail.conf for Mailbox locations and namespaces, and 10-auth.conf for Authentication processes.  Options specific to imap and pop3 are placed in their own files, 20-imap.conf for IMAP specific settings and 20-pop3.conf for POP3 specific settings.  Each file name is prefixed by a number which organizes them into the sequence in which they are read. Configuration categories such as authentication, logging, and mailbox are prefixed with a 10-, as in: 10-auth.conf, 10-logging.conf, and 10-mail.conf.  The imap and pop3 categories begin with 20-, as in 20-imap.conf and 20-pop3.conf. The acl, plugin, and quota categories are at the end: 90-acl.conf, 90-plugin.conf, and 90-quota.conf. 

Note: The IMAP and POP servers provide SSL encryption for secure e-mail transmissions. You can also run IMAP and POP servers using Stunnel to provide similar security. Stunnel is an SSL wrapper for daemons like imapd, popd, and even pppd (modem connections).

The configuration files contain commented default settings with detail explanations for each. These are some basic settings to configure:

protocols This can be set to imap, pop3, and lmtp, as well as imaps and pop3s for SSL-encrypted connections.

listen This can be set to IPv4 or IPv4 addresses on which to listen for connections.  The * character indicates all IPv4 network interfaces, and [::] on all IPv6 interfaces.

Authentication processes /etc/dovecot/conf.d/10-auth.conf This file holds your default authentication options. It reads in several .ext files which configure user controls.  For example, the auth-deny.conf.ext file is read by 10-auth.conf, which specifies the /etc/dovecot/deny-users file as a list of users to be denied access.

mechanism in Authentication processes in 10-auth.conf is plain by default. The digest-MD5 and cran-MD5 methods are supported, but they are not needed if you are using SSL.

mail_location The default mail storage method and location (10-mail.conf file).

Dovecot supports either mailbox or maildir (IMAP) storage formats. The mailbox format uses single large mailbox files to hold several mail messages. This will be the user's mbox file at /var/mail. Updates can be time-consuming. The maildir format uses a separate file for each message, making updates much more efficient. You can configure Dovecot to use a maildir format by setting the mail_location option to use a maildir setting, specifying the directory to use (conf.d/10-mail.conf). The %u variable can be used to represent the username, %h for the home directory. Messages will be stored in a user’s maildir directory instead of an mbox file. Be sure to create the maildir directory and give it read, write, and execute access The default maildir entry in the dovecot.conf file uses the Maildir subdirectory in the user's home directory ("Mailbox locations and namespaces" section).

mail_location=maildir:~/Maildir

The following sets up a maildir directories for users in the /var/mail directory using the domain name and username. The %n variable is the username extracted from a user name and domain entry (same as %u), and %d is the domain.

mail_location=maildir:/var/mail/%d/%1n/%n/maildir

If you have installed Postfix, then dovecot configures the user mail directory with the home_mailbox option in the /etc/postfix/main.cf file. This sets the mailbox directory to the Maildir directory in the user's home directory.

home_mailbox = Maildir/

Note: As an alternative to dovecot you could use the Cyrus IMAP server, which you can install and use instead of Dovecot. The Cyrus IMAP server (https://cyrusimap.org/) features security controls and authentication, using a private mailbox structure. Designed to be run on dedicated mail servers, it is supported and maintained by Carnegie Mellon.

Spam: SpamAssassin

With SpamAssassin, you can filter sent and received e-mail for spam. The filter examines both headers and content, drawing on rules designed to detect common spam messages. When they are detected, it then tags the message as spam, so that a mail client can then discard it. SpamAssassin will also report spam messages to spam detection databases. The version of SpamAssassin distributed for Linux is the open source version developed by the Apache project, located at http://spamassassin.apache.org. There you can find detailed documentation, FAQs, mailing lists, and even a listing of the tests that SpamAssassin performs.

SpamAssassin rule files are located at /usr/share/spamassassin. The files contain rules for running tests such as detecting the fake hello in the header. Configuration files for SpamAssassin are located at /etc/mail/spamassassin. The local.cf file lists system-wide SpamAssassin options such as how to rewrite headers. The init.pre file holds spam system configurations. The spamassassin-spamc.rc file will redirect all mail to the spamc client.

Users can set their own SpamAssassin option in their .spamassassin/user_prefs file. Common options include required_scorei, which sets a threshold for classifying a message as SPAM, numerous whitelist and blacklist options that accept and reject messages from certain users and domains, and tagging options that either rewrite or just add SPAM labels. Check the Mail::SpamAssassin::Conf Man page for details.

To configure procmail to use SpamAssassin, you need to have procmail run the /etc/mail/spamassassin/spamassassin-spamc.rc file. This will filter all mail through SpamAssassin. The spamassassin-spamc.rc file uses the spamd daemon, which means you have to have the SpamAssassin service running. The spamassassin-default.rc file runs a less efficient script to use SpamAssassin, instead of the daemon. If you want system wide procmail filtering, you use the /etc/procmailrc file; whereas to implement filtering on a per-user basis, you use a .procmail file in the user’s home directory. Within the respective procmail files, add the following at the top:

INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc

Mail Filtering: Amavisd-new

On Fedira, you can set up mail filtering using Amavisd-new, which invokes the ClamAV virus protection utility and SpamAssassin to filter mail,. You can also use external filters such as opendkim for Sendmail and python-policy-spf for Postfix. amavisd-new calls filtering tools as needed. Check https://www.ijs.si/software/amavisd for more details.

amavisd-new calls filtering tools as needed. First, a message is filtered using an external filter such as opendkim or python-policy-spf (Postfix will use both), then amavisd-new has the message scanned by ClamAV for viruses, followed by an analysis by SpamAssassin to see if it is spam. Only then does amavisd-new allow the message to be placed in the inbox.

To implement mail filtering, be sure you have installed amavisd-new, spamassassin, and clamav, along with the external filters.

sudo dnf install amavisd-new spamassassin clamav
sudo dnf install opendkim

You should also install supporting applications such as pyzor, razor, and the extraction utilities if you have not already done so (arg, capextract, cpio, lha, nomarch, pax, rar, unrar, unzip, zip). Add the clamav user to the amavis group to allow amavis to use clamav to scan files.

sudo adduser calmav amavis
sudo adduser amavis clamav

Enable and start spamassassin

sudo systemctl enable spamassassin
sudo systemctl start spamassassin

You can configure Amavisd-new using the amavisd.conf file in the /etc/amavisd directory. To activate virus detection and spamassassin, edit the file and uncomment the lines for virus detection as indicated by the comments.

You should also disable the bounce response for spam emails by settings the final_spam_destiny option in the amavisd.conf file to D_DISCARD instead of D_BOUNCE. You can also adjust the level of spam detection

$final_spam_destiny  =  D_DISCARD;

7. FTP

The File Transfer Protocol (FTP) is designed to transfer large files across a network from one system to another. Like most Internet operations, FTP works on a client/server model. FTP client programs can enable users to transfer files to and from a remote system running an FTP server program. Any Linux system can operate as an FTP server. It has to run only the server software—an FTP daemon with the appropriate configuration. Transfers are made between user accounts on client and server systems. A user on the remote system has to log in to an account on a server and can then transfer files to and from that account’s directories only. A special kind of user account, named ftp, allows any user to log in to it with the username “anonymous.” This account has its own set of directories and files that are considered public, available to anyone on the network who wants to download them. The numerous FTP sites on the Internet are FTP servers supporting FTP user accounts with anonymous login. Any Linux system can be configured to support anonymous FTP access, turning them into network FTP sites. Such sites can work on an intranet or on the Internet.

FTP Servers

FTP server software consists of an FTP daemon and configuration files. The daemon is a program that continuously checks for FTP requests from remote users. When a request is received, it manages a login, sets up the connection to the requested user account, and executes any FTP commands the remote user sends. For anonymous FTP access, the FTP daemon allows the remote user to log in to the FTP account using anonymous or ftp as the username. The user then has access to the directories and files set up for the FTP account. As a further security measure, however, the daemon changes the root directory for that session to be the FTP home directory. This hides the rest of the system from the remote user. Normally, any user on a system can move around to any directories open to the user, but a user logging in with anonymous FTP can see only the FTP home directory and its subdirectories. The remainder of the system is hidden from that user. This effect is achieved by the chroot operation (discussed later) that literally changes the system root directory for that user to that of the FTP directory. By default, the FTP server also requires a user be using a valid shell. It checks for a list of valid shells in the /etc/shells file. Most daemons have options for turning off this feature.

FTP Servers

Site

Very Secure FTP Server (vsftpd)

https://vsftpd.beasts.org

ProFTPD

https://www.proftpd.org

PureFTP

https://www.pureftpd.org

 Table 7-1: FTP Servers

Available Servers

Several FTP servers are available for use on Linux systems (see Table 7-1). Three of the more common servers include vsftpd, pureftpd, and proftpd. The Very Secure FTP Server provides a simple and very secure FTP server. The Pure FTPD servers is a lightweight, fast, and secure FTP server, based upon Troll-FTPD. Documentation and the latest sources are available from https://www.pureftpd.org. ProFTPD is a popular FTP daemon based on an Apache web server design. It features simplified configuration and support for virtual FTP hosts. The compressed archive of the most up-to-date version, along with documentation, is available at the ProFTPD website at https://www.proftpd.org.

FTP Users

Normal users with accounts on an FTP server can gain full FTP access simply by logging into their accounts. Such users can access and transfer files directly from their own accounts or any directories they may have access to. You can also create users, known as guest users that have restricted access to the FTP publicly accessible directories. This involves setting standard user restrictions, with the FTP public directory as their home directory. Users can also log in as anonymous users, allowing anyone on the network or Internet to access files on an FTP server.

 Anonymous FTP: vsftpd

An anonymous FTP site is essentially a special kind of user on your system with publicly accessible directories and files in its home directory. Anyone can log in to this account and access its files. Because anyone can log in to an anonymous FTP account, you must be careful to restrict a remote FTP user to only the files on that anonymous FTP directory. Normally, a user’s files are interconnected to the entire file structure of your system. Normal users have write access that lets them create or delete files and directories. The anonymous FTP files and directories can be configured in such a way that the rest of the file system is hidden from them and remote users are given only read access. ProFTPD and vsftpd implement secure access to system commands. An older approach involves having copies of certain system configuration, command, and library files placed within subdirectories of the FTP home directory. Restrictions placed on those subdirectories then control access by other users. Within the FTP home directory, you then have a publicly accessible directory that holds the files you want to make available to remote users. This directory usually has the name pub, for public.

An FTP site is made up of an FTP user account, an FTP home directory, and certain copies of system directories containing selected configuration and support files (ProFTPD does not need the system directories and support files).

 The FTP User Account: anonymous

To allow anonymous FTP access by other users to your system, you must have a user account named FTP. Most distributions already create this account for you. If your system does not have such an account, you will have to create one. You can then place restrictions on the FTP account to keep any remote FTP users from accessing any other part of your system. The entry for this account in your /etc/passwd file must be set up to prevent normal user access to it. The following is the entry you find in your /etc/passwd file on Fedora that sets up an FTP login as an anonymous user:

ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin

The x in the password field blocks the account, which prevents any other users from gaining access to it, thereby gaining control over its files or access to other parts of your system. The user ID, 14, is a unique ID. The comment field is FTP User. The login directory is /var/ftp. When FTP users log in to your system, they are placed in this directory. If a home directory has not been set up, create one and then change its ownership to the ftp user with the chown command.

 FTP Group

The group ID is the ID of the ftp group, which is set up only for anonymous FTP users. You can set up restrictions on the ftp group, thereby restricting any anonymous FTP users. Here is the entry for the ftp group you find in the /etc/group file. If your system does not have one, you should add it:

ftp:x:50:

 Creating New FTP Users

If you are creating virtual FTP hosts, you will need to create an FTP user for each one, along with its directories. For example, to create an FTP server for a host1-ftp host, you create a host1-ftp user with its own directory.

useradd -d /home/host1-ftp

This creates a user with a password entry as that described here:

host1-ftp:x:501:501::/home/host1-ftp:/bin/bash

You also need to create the corresponding home directory, /home/host1-ftp in this example, and set its permissions to give users restricted access.

mkdir /home/host1-ftp
chmod 755 /home/host1-ftp

In addition, you need to make sure that the root user owns the directory, not the new FTP users. This gives control of the directory only to the root user, not to any user that logs in.

chown root.root /home/host1-ftp

 Anonymous FTP Server Directories

The FTP home directory is named ftp and is placed in the /var directory. When users log in anonymously, they are placed in this directory. An important part of protecting your system is preventing remote users from using any commands or programs not in the restricted directories. For example, you would not let a user use your ls command to list filenames because ls is located in your /bin directory. At the same time, you want to let the FTP user list filenames using an ls command. Newer FTP daemons such as vsftpd and ProFTPD solve this problem by creating secure access to needed system commands and files, while restricting remote users to only the FTP site’s directories. Make sure that the FTP home directory is owned by the root user, not by the FTP user. Use the ls -ld command to check on the ownership of the FTP directory.

ls -ld /var/ftp

To change a directory’s ownership, you use the chown command, as shown in this example:

chown  root.root /var/ftp

Another more traditional solution is to create copies of certain system directories and files needed by remote users and to place them in the ftp directory where users can access them. A bin directory is placed in the ftp directory and remote users are restricted to it, instead of the system’s bin directory. Whenever they use the ls command, remote users are using the one in ftp/bin, not the one you use in /bin. If for some reason, you set up the anonymous FTP directories yourself, you must use the chmod command to change the access permissions for the directories so that remote users cannot access the rest of your system. Create an ftp directory and use the chmod command with the permission 555 to turn off write access: chmod 555 ftp. Next, make a new bin directory in the ftp directory, and then make a copy of the ls command and place it in ftp/bin. Do this for any commands you want to make available to FTP users. Then create an ftp/etc directory to hold a copy of your passwd and group files. Again, the idea is to prevent any access to the original files in the /etc directory by FTP users. The ftp/etc/passwd file should be edited to remove any entries for regular users on your system. All other entries should have their passwords set to x to block access. For the group file, remove all user groups and set all passwords to x. Create an ftp/lib directory, and then make copies of the libraries you need to run the commands you placed in the bin directory.

 Anonymous FTP Files

A directory named pub, located in the FTP home directory, usually holds the files you are making available for downloading by remote FTP users. When FTP users log in, they are placed in the FTP home directory (/var/ftp), and they can then change to the pub directory to start accessing those files (/var/ftp/pub). Within the pub directory, you can add as many files and directories as you want. You can even designate some directories as upload directories, enabling FTP users to transfer files to your system.

In each subdirectory set up under the pub directory to hold FTP files, you should create a README file and an INDEX file as a courtesy to FTP users. The README file contains a brief description of the kind of files held in this directory. The INDEX file contains a listing of the files and a description of what each one holds.

The Very Secure FTP Server

The Very Secure FTP Server (vsftpd) is small, fast, easy, and secure. It is designed to avoid the overhead of large FTP server applications like ProFTPD while maintaining a very high level of security. It can also handle a very large workload, managing high traffic levels on an FTP site. It is perhaps best for sites where many anonymous and guest users will be downloading the same files.

The Very Secure FTP Server is inherently designed to provide as much security as possible, taking full advantage of UNIX and Linux operating system features. The server is separated into privileged and unprivileged processes. The unprivileged process receives all FTP requests, interpreting them and then sending them over a socket to the privileged process, which then securely filters all requests. Even the privileged process does not run with full root capabilities, using only those that are necessary to perform its tasks.

For  detailed documentation and configuration of vsftpd on Fedora see the Fedora System Administration Guide | Servers | File and Print Servers | FTP.

https://docs.fedoraproject.org/f28/system-administrators-guide/servers/File_and_Print_Servers.html

The Very Secure FTP Server is managed by systemd using the vsftpd.service unit file, shown here. It is a simple file that is run after the network starts (After), and is started by the multi-user.target (runlevels 2, 3,4, and 5) (WantedBy). It is run by the /usr/sbin/vsftpd command with reads the /etc/vsftpd/vsftpd.conf file for configuration. 

vsftpd.service

[Unit]
Description=Vsftpd ftp daemon
After=network.target
[Service]
Type=forking
ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
[Install]
WantedBy=multi-user.target

Running vsftpd

The Very Secure FTP Server’s daemon is named vsftpd. It is designed to be run as a stand-alone server, which can be started and stopped using the /lib/systemd/system/vsftpd.service server script.

Be sure to enable it with the systemctl command and the enable argument, as shown here. Use the disable argument to disable the server. If you previously enabled another FTP server such as ProFTPD, be sure to disable it first.

sudo systemctl enable vsftpd
sudo systemctl start vsftpd

To start, stop, and restart vsftpd, you can use the systemctl command.

sudo systemctl start vsftpd

You also can use cockpit to start and stop vsftpd, or to have it started automatically.

Firewall access

To allow firewall access to the FTP port, usually port 21, you should enable access using the firewall configuration tool firewall-config and checking the FTP entry on the Services tab.

If you are managing your IPtables firewall directly, you could manage access by adding the following IPtables rule. This accepts input on port 21 for TCP/IP protocol packages (or use the trusted services tab on system-config-firewall).

iptables -A INPUT -p tcp --dport 21 -j ACCEPT

Configuring vsftpd

Configuration for vsftpd uses one configuration file, /etc/vsftpd/vsftpd.conf. Configuration options are simple and kept to a minimum (see Table 7-2). The vsftpd.conf file contains a set of directives where an option is assigned a value (there are no spaces around the = sign). Options can be on and off flags assigned a YES or NO value, features that take a numeric value, or ones that are assigned a string. A default vsftpd.conf file is installed in the /etc/vsftpd directory. This file lists some of the commonly used options available with detailed explanations for each. Those not used are commented out with a preceding # character. Option names are very understandable. For example, anon_upload_enable allows anonymous users to upload files, whereas anon_mkdir_write_enable lets anonymous users create directories. The Man page for vsftpd.conf lists all options, providing a detailed explanation for each.

Option

Description

listen

Set standalone mode.

listen_port

Specify the port for standalone mode.

anonymous_enable

Enable anonymous user access.

local_enable

Enable access by local users.

no_anon_password

Specify whether anonymous users must submit a password.

anon_upload_enable

Enable uploading by anonymous users.

anon_mkdir_write_enable

Allow anonymous users to create directories.

aonon_world_readable_only

Make uploaded files read-only to all users.

idle_session_timeout

Set time limit in seconds for idle sessions.

data_connection_timeouts

Set time limit in seconds for failed connections.

dirmessage_enable

Display directory messages.

ftpd_banner

Display FTP login message.

xferlog_enable

Enable logging of transmission transactions.

xferlog_file

Specify log file.

deny_email_enable

Enable denying anonymous users, whose e-mail addresses are specified in vsftpd.banned.

userlist_enable

Deny access to users specified in the vsftp.user_list file.

userlist_file

Deny or allow users access depending on setting of userlist_deny.

userlist_deny

When set to YES, userlist_file deny list users access. When set to NO, userlist_file allow list users, and only those users, access.

chroot_list_enable

Restrict users to their home directories.

chroot_list_file

Allow users access to home directories. Unless chroot_local_user is set to YES, this file contains a list of users not allowed access to their home directories.

chroot_local_user

Allow access by all users to their home directories.

pam_service_name

Specify PAM script.

ls_recurse_enable

Enable recursive listing.

user_config_dir

Directory for user specific configuration

 Table 7-2: Configuration Options for vsftpd.conf

See the Fedora System Administration Guide | Servers | File and Print Servers | FTP | vsftpd Configuration Options for a detailed listing of vsftpd options.

https://docs.fedoraproject.org/f28/system-administrators-guide/servers/File_and_Print_Servers.html

Enabling Standalone Access

To run vsftpd as a standalone server, you set the listen option to YES. This instructs vsftpd to continually listen on its assigned port for requests. The listen option is for IPv4 connections. You can specify the port it listens on with the listen_port option.

listen=NO

For IPv6 connections, uncomment the listen_ipv6 option. You can have either listen or listen_ipv6 options active, but not both.

listen_ipv6=Yes

Enabling Login Access

In the following example taken from the vsftpd.conf file, anonymous FTP is enabled by assigning the YES value to the anonymous_enable option. The local_enable option allows local users on your system to use the FTP server.

# Allow anonymous FTP?
anonymous_enable=YES
#
# Uncomment this to allow local users to log in.
local_enable=YES

Should you want to let anonymous users log in without providing a password, you can set no_anon_password to YES.

You can further specify the permissions for uploaded files using the local_umask option (022 is the default set in vsftpd.conf, read and write for the owner and read-only for all other users, 644).

local_umask=022

Local User Permissions

A variety of user permissions control how local users can access files on the server. If you want to allow local users to create, rename, and delete files and directories on their account, you have to enable write access with the write_enable option. This way, any files they upload, they can also delete. Literally, the write_enable option activates a range of commands for changing the file system, including creating, renaming, and deleting both files and directories. With user_config_dir you can configure specific users.

write_enable=YES

Because ASCII uploads entail certain security risks, they are turned off by default. However, if you are uploading large text files, you may want to enable them in special cases. Use ascii_upload_enable to allow ASCII uploads.

Anonymous User Permissions

You can also allow anonymous users to upload and delete files, as well as create or remove directories. Uploading by anonymous users is enabled with the anon_upload_enable option. To let anonymous users also rename or delete their files, you set the anon_other_write_enable option. To let them create directories, you set the anon_mkdir_write_enable option.

anon_upload_enable=YES
anon_other_write_enable=YES
anon_mkdir_write_enable=YES

The anon_world_readable_only option will make uploaded files read-only (downloadable), restricting write access to the user that created them. Only the user that uploaded a file can delete it.

All uploaded files are owned by the anonymous FTP user. You can have the files owned by another user, adding greater possible security. In effect, the actual user owning the uploaded files becomes hidden from anonymous users. To enable this option, you use chown_uploads and specify the new user with chown_username. Never make the user an administrative user like root.

chown_uploads=YES
chown_username=myftpfiles

The upload directory itself should be given write permission by other users.

sudo chmod 777 /var/ftp/upload

You can control the kind of access that users have to files with the anon_mask option, setting default read/write permissions for uploaded files. The default is 077, which gives read/write permission to the owner only (600). To allow all users read access, you set the umask to 022, where the 2 turns off write permission but sets read permission (644). The value 000 allows both read and write for all users.

Logging

A set of xferlog options control logging. You can enable logging, as well as specify the format and the location of the file.

xferlog_enable=YES
xferlog_std_format=YES

Use xferlog_file option to specify the log file you want to use. The default is shown here:

xferlog_file=/var/log/xferlog

Connection Time Limits

To more efficiently control the workload on a server, you can set time limits on idle users and failed transmissions. The idle_session_timeout option will cut off idle users after a specified time, and data_connection_timeouts will cut off failed data connections. The defaults are shown here:

idle_session_timeout=600
data_connection_timeout=120

Messages

The dirmessage_enable option allows a message held in a directory's .message file to be displayed whenever a user accesses that directory. The ftpd_banner option lets you set up your own FTP login message. The default is shown here:

ftpd_banner=Welcome to blah FTP service.

vsftpd Access Controls

Certain options control access to the FTP site. As previously noted, the anonymous_enable option allows anonymous users access, and local_enable permits local users to log in to their accounts (If /etc/vsftpd exits, as in Fedora, no vsftpd. prefix is used on files).

Denying Access

The deny_email_enable option lets you deny access by anonymous users, and the banned_email file option designates the file (usually /etc/vsftpd/banned) that holds the e-mail addresses of those users. The /etc/vsftpd/ftpusers file lists those users that can never be accessed. These are usually system users like root, mail, and nobody. See Table 7-3 for a list of vsftpd files.

File

Description

/etc/vsftpd/ftpusers

Users always denied access

/etc/vsftpd/user_list

Specified users denied access (allowed access if userlist_deny is NO)

vsftpd/chroot_list

Local users allowed access (denied access if chroot_local_user is on)

/etc/vsftpd/vsftpd.conf

vsftpd configuration file

/etc/pam.d/vsftpd

PAM vsftpd script

/lib/systemd/system/vsftpd.service

Systemd vsftpd unit file

 Table 7-3: Files for vsftpd

User Access

The userlist_enable option controls access by users, denying access to those listed in the file designated by the userlist_file option (usually /etc/vsftpd/user_list). If instead, you want to restrict access to just certain select users, you can change the meaning and usage of the /etc/vsftpd/user_list file to indicate only those users allowed access, instead of those denied access. To do this, you set the userlist_deny option to NO (its default is YES). Only users listed in the /etc/vsftpd/user_list file will be granted access to the FTP site.

User Restrictions

The chroot_list_enable option controls access by local users, letting them access only their home directories while restricting system access. The chroot_list_file option designates the file (usually /etc/vsftpd/chroot) that lists those users allowed access. You can allow access by all local users with the chroot_local_user option.

chroot_local_users=YES

If this option is set, then the file designated by chroot_list_file will have an inverse meaning, listing those users not allowed access. In the following example, access by local users is limited to those listed in/etc/vsftpd/chroot:

chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/chroot_list

User Authentication

The vsftpd server makes use of the PAM service to authenticate local users that are remotely accessing their accounts through FTP. In the vsftpd.conf file, the PAM script used for the server is specified with the pam_service_name option.

pam_service_name=vsftpd

In the /etc/pam.d directory, you will find a PAM file named vsftpd with entries for controlling access to the vsftpd server. PAM is currently set up to authenticate users with valid accounts, as well as deny access to users in the /etc/vsftpd/ftpusers file. The default /etc/pam.d/vsftpd file is shown here:

#%PAM-1.0
session    optional     pam_keyinit.so    force revoke
auth required pam_listfile.so item=user sense=deny file=/etc/vsftpd/ftpusers
                             onerr=succeed
auth      required   pam_shells.so
auth      include    password-auth
account   include    password-auth
account   include    system-auth
session   required   pam_loginuid.so
session   include    password-auth

 Command Access

Command usage is highly restricted by vsftpd. Most options for the ls command that lists files are not allowed. Only the asterisk file-matching operation is supported. To enable recursive listing of files in subdirectories, you have to enable the use of the -R option by setting the ls_recurse_enable option to YES.

vsftpd Virtual Hosts

You can configure and set up the vsftpd server to support virtual hosts. Virtual hosting is where a single FTP server operates as if it has two or more IP addresses. Several IP addresses can then be used to access the same server. The server will then use a separate FTP user directory and files for each host. With vsftpd, this involves manually creating separate FTP users and directories for each virtual host, along with separate vsftpd configuration files for each virtual host in the /etc/vsftpd directory. The vsftpd@service systemd template file will then read the configuration files listed in the /etc/vsftpd directory. The vsfptd@service file is shown here.

[Unit]
Description=Vsftpd ftp daemon
After=network.target
PartOf=vsftpd.target

[Service]
Type=forking
ExecStart=/usr/sbin/vsftpd /etc/vsftpd/%i.conf

[Install]
WantedBy=vsftpd.target

The following example uses two IP addresses for an FTP server. Create an FTP user for each host. Create directories for each host (you can use the one already set up for one of the users). For example, for the first virtual host you could use FTP-host1. Be sure to set root ownership and the appropriate permissions.

useradd -d /var/ftp-host1 FTP-host1
chown root.root /var/ftp-host1
chmod a+rx /var/ftp-host1
umask 022
mkdir /var/ftp-host1/pub

Within the /etc/vsftpd directory, create separate configuration files for each virtual host. Within each, specify the FTP user you created for each, using the ftp_username entry.

ftp_username = FTP-host1

The vsftpd@service file has a corresponding target file, vsftpd.target, which provides group configuration of all the vsftpd servers you start with this vsftpd@.service.  The vsftpd.target file starts the servers after the network.target file (network service files) and it is wanted by multi-user.target.

vsftpd.target

[Unit]
Description=FTP daemon
After=network.target

[Install]
WantedBy=multi-user.target

vsftpd Virtual Users

Virtual users can be implemented by making use of PAM to authenticate authorized users. In effect, you are allowing access to certain users, while not having to actually set up accounts for them on the FTP server system. First, create a PAM login database file to use along with a PAM file in the /etc/pam.d directory that will access the database. Then create a virtual FTP user along with corresponding directories that the virtual users will access (see the vsftpd documentation at https://vsftpd.beasts.org for more detailed information). Then, in the vsftpd.conf file, you can disable anonymous FTP:

anonymous_enable=NO
local_enable=YES

Then enable guest access.

guest_enable=YES
guest_username=virtual

Professional FTP Daemon: ProFTPD

ProFTPD is based on the same design as the Apache Web server, implementing a similar simplified configuration structure and supporting such flexible features as virtual hosting. ProFTPD is an open source project made available under a GPL license. You can download the current version from its Web site at https://www.proftpd.org. There you will also find detailed documentation including FAQs, user manuals, and sample configurations. ProFTPD is designed to be extensible, supporting dynamic modules that can be either custom made or provided by third-party developers. Currently, there are modules to provide LDAP and SQL authentication, along with numerous enhancement modules for such features as user quotas, logging formats, and time constraints.

install and startup

The ProFTPD server is available on the Fedora repository as the proftpd package. ProFTPD is managed by systemd using the proftpd.service unit file shown here. It is run after network startup and filesystem mounts. Runtime configuration options are read from /etc/sysconfig/proftpd (EnvironmentFile). The ftp server is started with the /usr/sbin/proftpd command  (ExecStart).  It is run for the multi-user.target (runlevels 2, 3, 4, and 5) (WantedBy).

profptd.service

[Unit]
Description = ProFTPD FTP Server
After = network.target nss-lookup.target local-fs.target remote-fs.target

[Service]
Type = simple
Environment = PROFTPD_OPTIONS=
EnvironmentFile = -/etc/sysconfig/proftpd
ExecStartPre = /usr/sbin/proftpd --configtest
ExecStart = /usr/sbin/proftpd --nodaemon $PROFTPD_OPTIONS
ExecReload = /bin/kill -HUP $MAINPID
PIDFile = /run/proftpd/proftpd.pid

[Install]
WantedBy = multi-user.target

A standalone process is continually running. You can start, stop, and restart the server using the systemctl command, as shown here:

sudo systemctl restart proftpd

You also can use cockpit to start and stop proftpd. Be sure to enable and start it.

sudo systemctl enable proftpd
sudo systemctl start proftpd

proftpd.config and .ftpaccess

ProFTPD uses only one configuration file, /etc/proftpd.conf. Configuration entries take the form of directives. This format is purposely modeled on Apache configuration directives. With the directives, you can enter basic configuration information, such as your server name, or perform more complex operations, such as implementing virtual FTP hosts. The design is flexible enough to enable you to define configuration features for particular directories, users, or groups. A basic configuration is shown here.

/etc/proftpd.conf

ServerName         "ProFTPD server"
ServerIdent        on "FTP Server ready."
ServerAdmin        root@localhost
DefaultServer      on
# Cause every FTP user except adm to be chrooted into their home directory
# Aliasing /etc/security/pam_env.conf into the chroot allows pam_env to
# work at session-end time (http://bugzilla.redhat.com/477120)
DefaultRoot               ~ !adm
# Use pam to authenticate (default) and be authoritative
AuthPAMConfig           proftpd
AuthOrder               mod_auth_pam.c* mod_auth_unix.c
# Don't do reverse DNS lookups (hangs on DNS problems)
UseReverseDNS               off
User          nobody
Group         nobody
MaxInstances    20
# ftptop and ftpwho
UseSendfile               off
# Define the log formats
LogFormat       default  "%h %l %u %t \"%r\" %s %b"
LogFormat        auth     "%v [%P] %h %t \"%r\" %s"
#Load supporting modules, see proftpd.conf file for details
LoadModule mod_vroot.c
#Statements conditional on loaded modules, see proftpd.conf file for entries
<IfModule mod_vroot.c>
  VRootEngine               on
</IfModule>
<Global>
   Umask     022
   AllowOverwrite    yes
   <Limit ALL SITE_CHMOD>
     AllowAll
   </Limit>
</Global>
# A basic anonymous configuration, with one incoming directory.
# Enable this with PROFTPD_OPTIONS=-DANONYMOUS_FTP in /etc/sysconfig/proftpd
<IfDefine ANONYMOUS_FTP>
<Anonymous ~ftp>
  User        ftp
  Group       ftp

  AccessGrantMsg   "Anonymous login ok, restrictions apply."
   MaxClients        10
  UserAlias         anonymous ftp
  DefaultChdir     /pub

  DisplayLogin      /welcome.msg
  DisplayChdir      .message
  DisplayReadme     README*

  # Cosmetic option to make all files appear to be owned by user "ftp"
  DirFakeUser      on ftp
  DirFakeGroup     on ftp

  # Limit WRITE everywhere in the anonymous chroot except incoming
    <Limit WRITE SITE_CHMOD>
         DenyAll
     </Limit>

  <Directory    uploads/*>
     <Limit READ>
            DenyAll
     </Limit>
       <Limit STOR>
            AllowAll
     </Limit>
  </Directory>

   # Don't write anonymous accesses to the system wtmp file (good idea!)
  WtmpLog               off
   # Logging for the anonymous transfers
   ExtendedLog               /var/log/proftpd/access.log WRITE,READ default
   ExtendedLog               /var/log/proftpd/auth.log AUTH auth

</Anonymous>
</IfDefine>

To configure a particular directory, you can use an .ftpaccess file with configuration options placed within that directory. These .ftpaccess options take precedence over those in the proftpd.conf directory. The .ftpaccess files are designed to operate like .htaccess files in the Apache Web server that configure particular Web site directories. You can find a complete listing of ProFTPD configuration parameters at the ProFTPD Web site (https://www.proftpd.org) and in the ProFTPD documentation installed in /usr/doc as part of the ProFTPD software package. Several of the more commonly used parameters are listed in Table 7-4. When creating a new configuration, you should make a copy of the proftpd.conf configuration file and modify it. Then you can test its syntax using the proftpd command with the -c option and the name of the file.

proftpd -c newfile.conf

Different kinds of directives exist. Many set values, such as MaxClients, which sets the maximum number of clients, or NameServer, which sets the name of the FTP server. Others create blocks that can hold directives that apply to specific FTP server components. Block directives are entered in pairs: a beginning directive and a terminating directive. The terminating directive defines the end of the block and consists of the same name, beginning with a slash. Block directives take an argument that specifies the particular object to which the directives will apply. For the Directory block directive, you must specify a directory name to which it will apply. The <Directory mydir> block directive creates a block whose directives within it apply to the mydir directory. The block is terminated by a </Directory> directive. <Anonymous ftp-dir> configures the anonymous service for your FTP server. You need to specify the directory on your system used for your anonymous FTP service, such as /var/ftp. The block is terminated with the </Anonymous> directive. The <VirtualHost hostaddress> block directive is used to configure a specific virtual FTP server and must include the IP or the domain name address used for that server. </VirtualHost> is its terminating directive. Any directives you place within this block are applied to that virtual FTP server. The <Limit permission> directive specifies the kind of access you want to limit. It takes as its argument one of several keywords indicating the kind of permission to be controlled: WRITE for write access, READ for read access, STOR for transfer access (uploading), and LOGIN to control user login.

Directive

Description

Allow [“from”] “all”|”none”|host|network
[,host|network[,...]]

Used inside a <Limit> context to specify explicitly which hosts and/or networks have access to the commands or operations being limited. Used with Order and Deny to create access control rules.
Default: Allow from all
Context: <Limit>

AllowAll

Allows access to a <Directory>, <Anonymous> or <Limit> block.

AllowFilter regular-expression

Allows the configuration of a regular expression that must be matched for all commands sent to ProFTPD.

AllowUser user-expression

Users allowed access.

<Anonymous root-directory>

Creates an anonymous FTP login, terminated by a matching </Anonymous> directive. The root directory parameter is the directory proftpd first moves to and then chroots to, hiding the rest of the file system.

Bind address

Allows additional IP addresses to be bound to a main or VirtualHost configuration. Multiple Bind directives can be used to bind multiple addresses.

DefaultRoot directory
[group-expression]

Default root directory assigned to a user on login. The group-expression argument restricts the DefaultRoot directive to a group or set of groups.
Default: DefaultRoot /

Deny [“from”]
“all”|”none”|host|network
[,host|network[,...]]

List of hosts and networks explicitly denied access to a given <Limit> context block. all indicates all hosts are denied access, and none indicates no hosts are explicitly denied.

DenyAll

Denies access to a directory, anonymous FTP, or Limit block.

DenyFilter regular-expression

Specifies a regular expression, which must not match any command.

DenyUser user-expression

Users denied access within a Limit block.

<Directory pathname>

Directory-specific configuration. Used to create a block of directives that apply to the specified directory and its subdirectories.

DisplayLogin filename

Specifies the text file displayed to a user who logs in.

<Global>

Global configuration block

<Limit command|command-group
[command2 ..]>

Access restrictions on FTP commands, within a given context. The command-group refers to groupings of commands as defined in the ProFTPD documentation.

LsDefaultOptions “options string”

Default options for directory listings (as in the ls command).

MasqueradeAddress host

Specifies public hostname for FTP server. Used for FTP servers masqueraded by NAT tables (packet filtering), see Chapter 19.

MaxClients number|none message

Maximum number of connected clients allowed. The message specified is displayed when a client is refused connection.

MaxLoginAttempts number

Maximum number of times a client may attempt to log in to the server during a given connection.

Order allow,deny|deny,allow

Configures the order that Allow and Deny directives are checked inside a <Limit> block.
Default: Order allow,deny
Context: <Limit>

PersistentPasswd on|off

When on, proftpd, during login, opens the system-wide /etc/passwd, /etc/group files, accessing them even during a chroot operation that changes the root directory.

ServerAdmin “admin-email-address”

E-mail address of the server or virtual host administrator.

ServerType type-identifier

The server daemon’s operating mode, standalone.

TimeoutIdle seconds

Maximum number of seconds proftpd allows clients to stay connected without any activity.
Default: TimeoutIdle 600

Umask octal-mask

Permissions applied to newly created file and directory within a given context.

User userid

The user the proftpd daemon runs as.

UserAlias login-user userid

Maps a login name used by a client to a user ID on the server. A client logging in as login-user is actually logged in as user ID. Often used inside an <Anonymous> block to allow specified login-names to perform an anonymous login.

<VirtualHost address>

Configuration directives that apply to a particular hostname or IP address. Often used with virtual servers that run on the same physical machine. The block is terminated with a </VirtualHost> directive.

Table 7-4: ProFTPD Configuration Directives, proftpd.conf

Entries from the standard proftpd.conf file installed as part of the ProFTPD software package is shown here. It establishes a single server and a single anonymous login. Notice the default ServerType is standalone. Detailed examples of proftpd.conf files, showing various anonymous FTP and virtual host configurations, can be found with the ProFTPD documentation, located in /usr/share/doc, and on the ProFTPD Web site at https://www.proftpd.org.

Authentication

Authentication of users in ProFTPD can be implemented either in PAM, LDAP, or SQL. For LDAP or SQL, you need to load the corresponding ProFTPD module. PAM authentication is the default. Be sure that a /etc/pam.d/proftpd file has been installed to provide PAM FTP support. ProFTPD also supports both standard passwords and shadow passwords. The default PAM authentication can be turned off by setting the AuthPAMAuthoritative directive to off, allowing other authentication methods such as LDAP to be used. If your server is further hidden in a local network by IP Masquerading techniques, you can use the MasqueradeAddress directive to specify its public hostname, allowing its real hostname to remain hidden.

Anonymous Access

You use the Anonymous configuration directive to create an anonymous configuration block in which you can place directives that configure your anonymous FTP service. The directive includes the directory on your system used for the anonymous FTP service. The ProFTPD daemon executes a chroot operation on this directory, making it the root directory for the remote user accessing the service. By default, anonymous logins are supported, expecting users to enter their e-mail address as a password. You can modify an anonymous configuration to construct more controlled anonymous services, such as guest logins and required passwords.

The following example shows a standard anonymous FTP configuration. The initial Anonymous directive specifies /var/ftp as the anonymous FTP home directory. The User directive specifies the user that the Anonymous FTP daemon will run as, and Group indicates its group. In both cases, FTP, the standard username, is used on most systems for anonymous FTP. A Directory directive with the * file-matching character then defines a Directory block that applies to all directories and files in /var/ftp. The * symbol matches on all filenames and directories. Within the Directory directive is a Limit directive that you use to place controls on a directory. The directive takes several arguments, including READ for read access and WRITE for write access. In this example, the Limit directive places restrictions on the write capabilities of users. Within the Limit directive, the DenyAll directive denies write permission, preventing users from creating or deleting files and effectively giving them only read access. A second Directory directive creates an exception to this rule for the incoming directory. An incoming directory is usually set up on FTP sites to let users upload files. For this directory, the first Limit directive prevents both READ and WRITE access by users with its DenyAll directive, effectively preventing users from deleting or reading files here. The second Limit directive allows users to upload files, however, permitting transfers only (STOR) with the AllowAll directive.

One important directive for anonymous FTP configurations is RequireValidShell. By default, the FTP daemon first checks to see if the remote user is attempting to log in using a valid shell, such as the BASH shell or the C shell. The FTP daemon obtains the list of valid shells from the /etc/shells file. If the remote user does not have a valid shell, a connection is denied. You can turn off the check using the RequireValidShell directive and the off option. The remote user can then log in using any kind of shell.

FTP was originally designed to let a remote user connect to an account of his or her own on the system. Users can log in to different accounts on your system using the FTP service. Anonymous users are restricted to the anonymous user account. However, you can create other users and their home directories that also function as anonymous FTP accounts with the same restrictions. Such accounts are known as guest accounts. Remote users are required to know the username and, usually, the password. Once connected, they have only read access to that account’s files; the rest of the file system is hidden from them. In effect, you are creating a separate anonymous FTP site at the same location with more restricted access.

<Anonymous /var/ftp>
    User ftp
    Group ftp
    UserAlias anonymous ftp
    RequireValidShell off

   <Directory *>
       <Limit WRITE>
               DenyAll
       </Limit>
    </Directory>

     # The only command allowed in incoming is STOR
     # (transfer file from client to server)
    <Directory incoming>
       <Limit READ WRITE>
              DenyAll
       </Limit>

       <Limit STOR>
               AllowAll
       </Limit>
    </Directory>

</Anonymous>

To create a guest account, first, create a user and the home directory for it. You then create an Anonymous block in the proftpd.conf file for that account. The Anonymous directive includes the home directory of the guest user you create. You can specify this directory with a ~ for the path and the directory name, usually the same as the username. Within the Anonymous block, you use the User and Group directives to specify the user and group name for the user account. Set the AnonRequirePassword directive to on if you want remote users to provide a password. A UserAlias directive defines aliases for the username. A remote user can use either the alias or the original username to log in. You then enter the remaining directives for controlling access to the files and directories in the account’s home directory. An example showing the initial directives is listed here. The User directive specifies the user as myproject. The home directory is ~myproject, which usually evaluates to /var/myproject. The UserAlias lets remote users log in with either the name myproject or mydesert.

<Anonymous ~myproject>
    User myproject
    Group other
    UserAlias mydesert myproject
    AnonRequirePassword on
    <Directory *>

You could just as easily create an account that requires no password, letting users enter their e-mail addresses instead. The following example configures an anonymous user named mypics. A password isn’t required, and neither is a valid shell. The remote user still needs to know the username, in this case, mypics.

<Anonymous /var/mypics>
    AnonRequirePassword off
    User mypics
    Group nobody
    RequireValidShell off
    <Directory *>

The following example provides a more generic kind of guest login. The username is guest, with the home directory located at ~guest. Remote users are required to know the password for the guest account. The first Limit directive lets all users log in. The second Limit directive allows write access from users on a specific network, as indicated by the network IP address, and denies write access by any others.

<Anonymous ~guest>
  User            guest
  Group           nobody
  AnonRequirePassword      on
  <Limit LOGIN>
         AllowAll
  </Limit>

  # Deny write access from all except trusted hosts.
  <Limit WRITE>
         Order        allow,deny
         Allow        from 10.0.0.
         Deny         from all
  </Limit>
</Anonymous>

Virtual FTP Servers

The ProFTPD daemon can manage more than one FTP site at once. Using a VirtualHost directive in the proftpd.conf file, you can create an independent set of directives that configure a separate FTP server. The VirtualHost directive is usually used to configure virtual servers as FTP sites. You can configure your system to support more than one IP address. The extra IP addresses can be used for virtual servers, not independent machines. You can use such an extra IP address to set up a virtual FTP server, giving you another FTP site on the same system. This added server would use the extra IP address as its own. Remote users could access it using that IP address, instead of the system’s main IP address. Because such an FTP server is not running independently on a separate machine but is, instead, on the same machine, it is known as a virtual FTP server or virtual host. This feature lets you run what appear to others as several different FTP servers on one machine. When a remote user uses the virtual FTP server’s IP address to access it, the ProFTPD daemon detects that request and operates as the FTP service for that site. ProFTPD can handle a great many virtual FTP sites at the same time on a single machine.

Note: Given its configuration capabilities, you can also tailor any of the virtual FTP sites to specific roles, such as a guest site, an anonymous site for a particular group, or an anonymous site for a particular user.

You configure a virtual FTP server by entering a <VirtualHost> directive for it in your proftpd.conf file. Such an entry begins with the VirtualHost directive and the IP address and ends with a terminating VirtualHost directive, </VirtualHost>. Any directives placed within these are applied to the virtual host. For anonymous or guest sites, add Anonymous and Guest directives. You can even add Directory directives for specific directories. With the Port directive on a standalone configuration, you can create a virtual host that operates on the same system but connects on a different port.

<VirtualHost 10.0.0.1>
      ServerName "My virtual FTP server"
</VirtualHost>

The following example shows a sample configuration of a virtual FTP host. The VirtualHost directives use domain name addresses for its arguments. When a domain name address is used, it must be associated with an IP address in the network’s domain name server. The IP address, in turn, has to reference the machine on which the ProFTPD daemon is running. On the ftp.mypics.com virtual FTP server, an anonymous guest account named robpics is configured that requires a password to log in. An anonymous FTP account is also configured that uses the home directory /var/ftp/virtual/pics.

<VirtualHost ftp.mypics.com>
  ServerName         "Mypics FTP Server"
  MaxClients         10
  MaxLoginAttempts      1
  DeferWelcome         on
  <Anonymous ~robpics>
    User         robpics
    Group        robpics
    AnonRequirePassword      on
  <Anonymous /var/ftp/virtual/pics>
    User         ftp
    Group        ftp
    UserAlias    anonymous ftp
  </Anonymous>
  <Limit LOGIN>
     AllowAll
  </Limit>
</VirtualHost>

ProFTPD Server Tools

The ProFTPD daemons provide a set of FTP tools you can use to manage your FTP server. With the ftpshut command, you can smoothly shut down a running server, warning users of the shutdown well before it happens. ftpwho can tell you who is currently connected and what they are doing. ftpcount can give you the number of connections currently in effect. Although each daemon has its own set of tools, they perform the same action with much the same set of options. Tools provided by ProFTPD have the same name and options, though ProFTPD provides more information on virtual hosts and has some added options.

ftpshut

With the ftpshut command, you can have the FTP server shut down at a given time, rather than suddenly shutting it down by killing its process. This gives you the chance to warn users the server is shutting down and not to start any long downloads. ftpshut takes several options for specifying the time and including a warning message. ftpshut takes as its arguments the time until the shutdown, followed by the warning message you want sent to users. The time can be a word such as “now” that effects an immediate shutdown, a + sign with the number of minutes remaining, or a specific time of day indicated by an HHMM format, where HH is the hour in a 24-hour cycle and MM is the minute. The following example shuts down the FTP server in ten minutes, issuing a warning to users:

ftpshut +10  "Shutdown in ten minutes"

Shutdown disables any new FTP access ten minutes before a scheduled shutdown, though this can be changed using the -l option with the number of minutes you want. Five minutes before a scheduled shutdown, all current connections are disconnected. You can adjust the time with the -d option. The warning message is formatted at 75 characters, and you can use special formatting symbols for in-place substitutions of certain values in the warning message, such as the shutdown time. These symbols are called magic cookies. For example, %s is the shutdown time, %r is the time when new connections are refused, %d is the time when current connections are cut, %M is the maximum number of users, and %L is the local hostname.

ftpwho and ftpcount

With the ftpwho command, you can find out who is currently connected to your FTP server. ftpwho shows the current process information for each user. The output displays five fields: the process ID, the tty connection, the status of the connection, the amount of CPU time used so far for the process, and the connection details. The status of the connection is R for running, S for sleeping, and Z for crashed. The connection details include the Internet address from where the connection is made, the user making the connection, and the task currently being performed, such as downloading a file. The field begins with the name of the FTP daemon, usually ftpd, followed by the different segments separated by colons.

The ftpcount command displays the number of users connected to your FTP server, broken down according to the classes specified in your .ftpaccess file. Along with the number of users, it shows the maximum number allowed to connect.

Using FTP with rsync

Many FTP servers also support rsync operations using rsync as a daemon. This allows intelligent incremental updates of files from an FTP server. You can update multiple files in a directory or a single file such as a large ISO image.

 Accessing FTP Sites with rsync

To access the FTP server running an rsync server, you enter the rsync command, and following the hostname, you enter a double colon and then either the path of the directory you want to access or one of the FTP server’s modules. In the following example, the user updates a local myproject directory from the one on the mytrek.com FTP site:

rsync ftp.mytrek.com::/var/ftp/pub/myproject  /home/myproject

To find out what directories are supported by rsync, you check for rsync modules on that site. These are defined by the site's /etc/rsyncd.conf configuration file. A module is just a directory with all its subdirectories. To find available modules, you enter the FTP site with a double colon only.

rsync ftp.mytrek.com::
ftp

This tells you that the ftp.mytrek.com site has an FTP module. To list the files and directories on the module, you can use the rsync command with the -r option.

rsync -r ftp.mytrek.com::ftp

Many sites that run the rsync server will have an rsync protocol that will already be set to access the available rsync module (directory). You can even use rsync to update just a single file, such as an ISO image that may have been changed.

 Configuring an rsync Server

To configure your FTP server to let clients use rsync on your site, you need to first run rsync as a server. Use systemctl or cockpit to turn on the rsync daemon. This will run the rsync daemon using the rsyncd.service unit file.

When run as a daemon, rsync will read the /etc/rsyncd.conf file for its configuration options. Here you can specify FTP options such as the location for the FTP site files. The configuration file is segmented into modules, each with its own options. A module is a symbolic representation of a exported tree (a directory and its subdirectories). The module name is enclosed in brackets, for instance, [ftp] for an FTP module. You can then enter options for that module, as by using the path option to specify the location of your FTP site directories and files. The user and group IDs can be specified with the uid and gid options. The default is nobody. A sample FTP module for anonymous access is shown here:

[ftp]
        path = /var/ftp/pub
        comment = ftp site

For more restricted access, you can add an auth users option to specify authorized users; rsync will allow anonymous access to all users by default. The hosts allow or deny to control access control access from specific hosts. Access to areas on the FTP site by rsync can be further controlled using a secrets file, such as /etc/rsyncd.secrets. This is a colon-separated list of usernames and passwords.

aleina:mypass3
larisa:yourp5

A corresponding module to the controlled area would look like this:

[specialftp]
      path = /var/projects/special
      command = restricted access
      auth users = aleina,larisa
      secrets file = /etc/rsyncd.secrets

If you are on your FTP server and want to see what modules will be made available, you can run rsync with the localhost option and nothing following the double colon.

$ rsync localhost::
ftp
specialftp

Remote users can find out what modules you have by entering your hostname and double colon only.

rsync ftp.mytrek.com::

 rsync Mirroring

Some sites will allow you to use rsync to perform mirroring operations. With rsync, you do not have to copy the entire site, just those files that have been changed. The following example mirrors the mytrek FTP site to the /var/ftp/mirror/mytrek directory on a local system:

rsync -a --delete ftp.mytrek.com::ftp /var/ftp/mirror/mytrek

The -a option is archive mode, which includes several other options, such as -r (recursive) to include all subdirectories, -t to preserves file times and dates, -l recreate symbolic links, and -p to preserve all permissions. In addition, the --delete option is added to delete files that don't exist on the sending side, removing obsolete files.

8. Web Servers

The primary web server for Fedora is Apache, which has almost become the standard web server for all Linux distributions. It is a very powerful, stable, and fairly easy-to-configure system. Fedora provides a default configuration for the Apache, making it usable as soon as they are installed. Also available is lighttpd, a small fast Web server with few system requirements, and both cherokee and thttpd, tiny stripped down very fast Web servers. Table 8-1 lists various Web server Web sites.

In additions, the Zope Application server for Web development is included on the Fedora repository. Zope application server (https://www.zope.org) is an open source web server with integrated security, web-based administration and development, and database interface features. It was developed by the Zope Corporation, which also developed the Python programming language.

Website

Description

https://www.apache.org

Apache Software Foundation

https://httpd.apache.org

Apache HTTP Server Project

https://jakarta.apache.org

Jakarta Apache Project

https://www.lighttpd.net/

The Lighttpd Webserver

https://www.cherokee-project.com

The cherokee Web server

https://www.acme.com/software/thttpd/

The thttpd tiny http server

https://www.php.net

PHP Hypertext Preprocessor, embedded web page programming language

https://www.zope.org

Zope application server

 Table 8-1: Web server Websites

Lighttpd Web Server

The Lighttpd Webserver is a very fast lightweight Web server. The Lighttpd Web site is https://www.lighttpd.net. On the site, you can access documentation which includes tutorials and detailed descriptions.

Lighttpd uses the lighttpd directory in the Web server site directory, /var/www/lighttpd. Its configuration files are located at /etc/lighttpd. Server variables are set in the /etc/sysconfig/lighttpd file. You can start and stop the server using the systemctl command or cockpit. Use the systemctl command to enable it.

sudo systemctl enable lighttpd
sudo systemctl start lighttpd

Just as with Apache, you can access the Web server using the localhost URL with port 80.

http://localhost:80

The Lighttpd configuration file is /etc/lighttpd/lighttpd.conf. The configuration file holds a series of simple Web configuration options such as server.document-root for the Web site files (/var/www/lighttpd is the default), server.errorlog for the log file, and index-file.names for the name of the index HTML file to use. The server user name (server.username) is set to lighttpd. Entries can also be conditionals, used to check for certain values like a virtual Web address, and then, within an attached block, list options or conditionals that apply if the condition is true.

Note: The varnish server provides high-performance HTTP acceleration (varnish package), https://varnish-cache.org/docs/.

Detailed documentation is located in the /usr/share/doc/lighttpd* directory, which holds text files for different modules and features, like evhost.txt for Enhanced virtual hosts and authentication.txt for authentication methods. Check the configuration.txt file for a detailed description of configuration options with examples.

Lighttpd can be expanded easily using supported modules. Several are included such as mod_simple-vhost for virtual hosts, though almost all are initially disabled in the lighttpd.conf file. In the server.modules block at the top of the file, you will find the basic modules listed, though commented out. The module name begins with a mod_  prefix, as in mod_auth. Remove the comment character (#) on a module's entry to enable loading of the module. The Fedora repository also provides packages for additional modules including FastCGI, GeoIP for locations, and virtual hosts with MySQL database support. The Lighttpd modules are located in the /usr/lib/lighttpd directory.

Should you want to run both Apache and Lighttpd, you could change the port that Lighttpd uses to 81 in the /etc/lighttpd/lighttpd.conf file.

server.port = 81

Simple virtual hosts can be set up with the simple-vhost options for server, default-host, and document-root (mod_simple_vhost module). For enhanced virtual hosts, Lighttpd will rewrite the URL to a predetermined directory specified by the evhost.path-pattern option (mod_evhost module).

Apache Web Server

The Apache web server is a full-featured free HTTP (web) server developed and maintained by the Apache Server Project. The aim of the project is to provide a reliable, efficient, and easily extensible web server, with free open source code made available under its own Apache Software License. The server software includes the server daemon, configuration files, management tools, and documentation. The Apache Server Project is maintained by a core group of volunteer programmers and supported by a great many contributors worldwide. The Apache Server Project is one of several projects currently supported by the Apache Software Foundation (formerly known as the Apache Group). This nonprofit organization provides financial, legal, and organizational support for various Apache Open Source software projects, including the Apache HTTPD Server, Java Apache, Jakarta, and XML-Apache. The website for the Apache Software Foundation is https://www.apache.org. Table 8-1 lists various Apache-related websites.

Apache was originally based on the NCSA web server developed at the National Center for Supercomputing Applications, University of Illinois, Urbana-Champaign. Apache has since emerged as a server in its own right and become one of the most popular web servers in use. Although originally developed for Linux and Unix systems, Apache has become a cross-platform application with Windows and OS/2 versions. Apache provides online support and documentation for its web server at https://httpd.apache.org. An HTML-based manual is also provided with the server installation.

For detailed documentation on the use and configuration of the Apache Web server on Fedora see the Fedora System Administration Guide | Servers | Web Servers.

https://docs.fedoraproject.org/f28/system-administrators-guide/servers/Web_Servers.html

Web Site Directories

Description

/var/www/html

Web site Web files

/var/www/cgi-bin

CGI program files

/var/www/manual

Apache Web server manual (httpd-manual package)

Configuration Files

.htaccess

Directory-based configuration files; an .htaccess file holds directives to control access to files within the directory in which it is located

/etc/httpd/conf

Directory for Apache Web server configuration files

/etc/httpd/conf/httpd.conf

Apache Web server configuration file

/etc/httpd/conf.d

Directory holding module configuration files like ssl.conf for SSL, php.conf for PHP, and welcome.conf for the Welcome message.

Service Scripts

httpd.service

The systemd service script for the Apache Web server.

/etc/sysconfig/httpd

Red Hat and Fedora configuration options for Web server daemon, as used by the httpd service script

Application and Module Files

/usr/sbin

Location of the Apache Web server program file and utilities

/usr/share/doc/

Apache Web server documentation

/var/log/http

Location of Apache log files

/etc/httpd/modules

Directory holding Apache modules, link to /usr/lib/httpd/modules

/etc/httpd/run

Directory holding Apache process IDs, link to /var/run

 Table 8-2: Apache Web Server Files and Directories

Linux Apache Installation

Installing the Fedora httpd package sets up the Apache Web. All the necessary directories and configuration files are automatically generated for you. Then, whenever you run Linux, your system becomes a fully functional Web site.

The Web server normally sets up your Web site in the /var/www directory. It also sets up several directories for managing the site. The /var/www/cgi-bin directory holds the CGI scripts, and /var/www/manual holds the Apache manual in HTML format if you install the httpd-manual package. You can use your browser to examine it. Your Web pages are to be placed in the /var/www/html directory. Place your Web pages in this directory or in any subdirectories. Your configuration files are located in a different directory, /etc/httpd/conf. Table 8-2 lists the various Apache Web server directories and configuration files.

Apache also installs several management applications such as apachectl for starting and stopping the server. The Apache server is managed by systemd using the httpd.service unit file and the httpd.socket file, shown here. The server is started after the network and file system mounts (After). It reads runtime configuration information from /etc/sysconfig/httpd. The /usr/sbin/httpd command is used to start, stop, and restart the server (ExecStart, ExecStop, ExecReload). It is run by the multi-user.target (runlevels 2, 3, 4, and 5) (WantedBy).

httpd.service

[Unit]
Description=The Apache HTTP Server
Wants=httpd-init.service
After=network.target remote-fs.target nss-lookup.target httpd-init.service
Documentation=man:httpd.service(8)

[Service]
Type=notify
Environment=LANG=C
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
# Send SIGWINNCH for graceful stop
KillSgnal=SIGWINCH
KillMode=mixed
PrivateTmp=true

[Install]
WantedBy=multi-user.target

httpd.socket

[Unit]
Description=Apache httpd Server Socket
Documentation=man:httpd.socket(8)
[Socket]
ListenStream=80
NoDelay=true
DefaultAcceptSec=30

[Install]
WantedBy=sockets.target

To modify the httpd.service file, you can either copy it to the /etc/systemd/system directory and make your changes in that copy. Alternatively, you can create a configuration file in the /lib/systemd/system/httpd.service.d directory, such as local.conf. Such configuration files have a .conf extension and are read in as part of the service file, taking priority. The same options work for the httpd.socket file, using the httpd.socket.d directory. 

You can use the systemctl command to safely stop, restart, and stop your Web server. You can also use cockpit for the same purpose. You can use system-config-httpd to configure your Web server, accessible from Applications overview, System Tools  filter as HTTP. Table 8-3 lists some of the applications. See https://httpd.apache.org/docs/2.4/programs/ for a complete list.

Application

Description

apachectl

Control start, stop, and restart the apache server

system-config-httpd

Fedora desktop configuration tool for the Apache Web server

htcacheclean

Limit the size of the Web site disk cache

ab

Tool to benchmark Web site performance

htpasswd

Manage passwords for website directories

httpd.service

Apache Web server service script for systemd

 Table 8-3: Apache management tools

Apache Multiprocessing Modules: MPM

Apache uses multiprocessing modules (MPMs), which are designed to customize Apache to different operating systems, as well as handle certain multiprocessing operations. For the main MPM, a Linux system would use either the prefork or worker MPM, whereas Windows would use the mpm_winnt MPM. The prefork is a standard MPM module designed to be compatible with older Unix and Linux systems, particularly those that do not support threading. It is the module loaded by default by Fedora. The worker MPM implements threading for Apache server processes, a feature supported by the Native POSIX Thread Libraries (NPTL) that is part of Red Hat and Fedora. You can configure the workload parameters for both in the Apache configuration file, /etc/httpd/conf/httpd.conf. You can specify whether to use the worker module instead of the prefork module in the /etc/sysconfig/httpd configuration file.

Many directives that once resided in the Apache core are now placed in respective modules and MPMs. With this modular design, several directives have been dropped, such as ServerType. Configuration files for these modules are located in the /etc/httpd/conf.d directory.

Starting and Stopping the Web Server

On most systems, Apache is installed as a stand-alone server, continually running. As noted in Chapter 5, in the discussion of systemd, your system automatically starts up the Web server daemon, invoking it whenever you start your system. A service script for the Web server called httpd.service is in the /lib/systemd/system directory.

From the desktop you can enable or disable the Apache Web server and start and stop the server manually, using cockpit. The name of the Apache Web server is httpd.

Use the systemctl command to enable and disable the server, as well as to start, stop, and restart it.

sudo systemctl enable httpd
sudo systemctl start httpd

You also can use systemctl command to start and stop the httpd server manually. This may be helpful when you are testing or modifying your server. The httpd script with the start option starts the server, the stop option stops it, and restart will restart it. Simply killing the Web process directly is not advisable.

sudo systemctl restart httpd

The /etc/sysconfig/httpd configuration file is used to set options for the httpd service script. Here you can specify such options as whether to use the worker or prefork Apache MPM modules.

Apache also provides a control tool called apachectl (Apache control) for managing your Web server. With apachectl, you can start, stop, and restart the server from the command line. The apachectl command takes several arguments: start to start the server, stop to stop it, restart to shut down and restart the server, and graceful to shut down and restart gracefully. In addition, you can use apachectl to check the syntax of your configuration files with the config argument.

sudo apachectl graceful

The httpd service script calls the actual httpd daemon. It is possible to call the daemon directly using its full pathname, though this is not recommended. This daemon has several options. The -d option enables you to specify a directory for the httpd program if it is different from the default directory. With the -f option, you can specify a configuration file different from httpd.conf. The -v option displays the version.

/usr/sbin/httpd -v

To check your Web server, start your Web browser and enter the Internet domain name address of your system. For the system turtle.mytrek.com, the user enters http://turtle.mytrek.com. This should display the home page you placed in your Web document root directory, /var/www/html. Be sure to place an index.html file in the /var/www/html directory first.

Once you have your server running, you can check its performance with the ab benchmarking tool, also provided by Apache: ab shows you how many requests at a time your server can handle. Options include -v, which enables you to control the level of detail displayed, -n, which specifies the number of requests to handle (default is 1), and -t, which specifies a time limit.

Apache Configuration

Configuration directives are placed in the httpd.conf configuration file. A documented version of the httpd.conf configuration file is installed automatically in /etc/httpd/conf. It is strongly recommended that you consult this file on your system. It contains detailed descriptions and default entries for Apache directives.

Any of the directives in the main configuration files can be overridden on a per-directory basis using an .htaccess file located within a directory. Although originally designed only for access directives, the .htaccess file can also hold any resource directives, enabling you to tailor how Web pages are displayed in a particular directory. You can configure access to .htaccess files in the httpd.conf file.

In addition, many of the modules provided for Apache have their own configuration files. These are places in the /etc/httpd/conf.d directory.

Apache Configuration with system-config-httpd

You can use the Fedora Web administration tool, system-config-httpd, to perform basic configuration tasks, using a desktop interface. system-config-httpd is an older desktop application. Though deprecated on Red Hat and Centos, it is still available on the Fedora repository, though it is no longer supported. It may work well on Fedora 28.

The Wayland display server does not allow root access by default to graphical tools, such as system-config-httpd. Many of these older graphical administration tools were designed for the older Xorg server and have not been updated for the Wayland server. A work around uses the xhost command to add an access control for the root user to the local user. In a terminal window, enter the following command to enable root access through the display server. You have to re-enter this command with each new login session in order to use the older Xorg-based administration applications.

xhost +si:localuser:root

You can open system-config-httpd from the Applications overview on the Fedora Workstation as HTTP. It opens the HTTP Server Configuration dialog with three tabs: Main, Virtual Hosts, and Performance Tuning (see Figure 8-1). In each of these, you will see buttons to open dialog boxes where you can enter settings. Click the Help button to display a Web page–based reference manual that details how to use each tab.

Figure 8-1: system-config-httpd Server Configuration

On the Main tab, you enter your Web server address, the Web master’s e-mail address, and the addresses and ports the Web server will be listening on.

When the Apache Configuration Tool saves its settings, it will overwrite the Apache configuration file, /etc/httpd/conf/httpd.conf. It is advisable that you first make a backup copy of your httpd.conf file in case you want to restore the original settings created by your distribution for Apache. If you have already edited this file manually, you will receive a warning, and the Apache Configuration Tool will make a backup copy in /etc/httpd/conf/httpd.conf.bak.

The Performance Tuning tab sets limits on connections, like the maximum number of connections and the period for time-out (see Figure 8-2)

The Virtual Hosts tab is where you can configure particular sites, including the default site (see Figure 8-3). Virtual hosts are listed, beginning with the Default Virtual Host. Use the Add button to add a new host, and the Edit button to modify current ones. The delete button removes the host. To change global settings, click the Edit Default Settings button.

On the Virtual Hosts tab, select Default Virtual Host and click Edit to set the default settings for server options, page searches, SSL support, log files, CGI environment support, and directories (Performance). To add a virtual host, click the Add button to open a dialog where you can enter host information such as the virtual hostname and IP address. You can select different configuration tabs for the virtual host, such as log files and directory controls.

.

Figure 8-2: system-config-httpd Performance Tuning

Figure 8-3: system-config-httpd Virtual Hosts

Adding or editing a virtual host opens the Virtual Hosts Properties window, listing five tabs: General Options, Page Options, SSL, Logging, Environment, and Performance (see Figure 8-4).

Figure 8-4: system-config-httpd Virtual Hosts Properties, General Options

On the General Options tab, you specify the host name, its site directory, administrator address and the type of virtual host, Name or IP. You can also add aliases. On Page Options you can specify the type of file that will be searched for automatically and displayed. This is usually index.html and any of its variations like index.htm. You could specify your own.

Figure 8-5: system-config-httpd Virtual Hosts Properties | Performance | Directory

On the SSL tab, you can enable SSL support, specifying certificates to use along with SSL options. The Logging tab specifies the log and error logs. On the Environment tab, you can define environment variables for your CGI scripts, as well as those you want to pass to your scripts and those you want undefined.

The Performance tab control directory access features like access controls and directory capabilities like executing CGI scripts or following symbolic links. At the top of the tab is a button for editing default directory options. This opens a window that lists possible directory options, with the enabled ones checked. From the directory list, you can select a particular directory to edit. Click the Add button to add a new directory. This opens a Directory Options window with the possible options displayed on the right and the access control options on the left (see Figure 8-5). For Deny and Allow lists you can specify your own files.

Apache Configuration Directives

Apache configuration operations take the form of directives entered into the Apache configuration files. With these directives, you can enter basic configuration information, such as your server name, or perform more complex operations, such as implementing virtual hosts. The design is flexible enough to enable you to define configuration features for particular directories and different virtual hosts. Apache has a variety of different directives performing operations as diverse as controlling directory access, assigning file icon formats, and creating log files. Most directives set values such as DirectoryRoot, which holds the root directory for the server’s web pages, or Port, which holds the port on the system that the server listens on for requests. The syntax for a simple directive is shown here:

directive option option ...

Certain directives create blocks able to hold directives that apply to specific server components (also referred to as sectional directives). For example, the Directory directive is used to define a block within which you place directives that apply only to a particular directory. Block directives are entered in pairs: a beginning directive and a terminating directive. The terminating directive defines the end of the block and consists of the same name beginning with a slash. Block directives take an argument that specifies the particular object to which the directives apply. For the Directory block directive, you must specify a directory name to which it will apply. The <Directory mydir> block directive creates a block whose directives within it apply to the mydir directory. The block is terminated by a </Directory> directive. The <VirtualHost hostaddress> block directive is used to configure a specific virtual web server and must include the IP or domain name address used for that server. </VirtualHost> is its terminating directive. Any directives you place within this block are applied to that virtual web server. The <Limit method> directive specifies the kind of access method you want to limit, such as GET or POST. The access control directives located within the block list the controls you are placing on those methods. The syntax for a block directive is as follows:

<block-directive option ... >
  directive option ...
  directive option ...
</block-directive>

Global directives are placed in the main configuration file, /etc/httpd/conf/httpd.conf. Directory directives in that file can be used to configure a particular directory. However, Apache also makes use of directory-based configuration files. Any directory may have its own .htaccess file that holds directives to configure only that directory. If your site has many directories, or if any directories have special configuration needs, you can place their configuration directives in their .htaccess files, instead of filling the main configuration file with specific Directory directives for each one. You can control what directives in an .htaccess file take precedence over those in the main configuration files. If your site allows user or client controlled directories, you may want to carefully monitor or disable the use of .htaccess files in them. (It is possible for directives in an .htaccess file to override those in the standard configuration files unless disabled with AllowOverride directives.)

You can find a complete listing of Apache web configuration directives at the Apache website, https://httpd.apache.org/docs/2.4/mod/directives.html.

A set of commonly used directives is also available in the Fedora System Administration Guide | Servers | Web Servers | Common httpd.conf Directives.

https://docs.fedoraproject.org/f28/system-administrators-guide/servers/Web_Servers.html

Global Configuration

The standard Apache configuration has three sections: global settings, server settings, and virtual hosts. The global settings control the basic operation and performance of the web server (see Table 8-4). Here you set configuration locations, process ID files, timing, settings for the MPM module used, and what Apache modules to load.

The ServerTokens directive prevents disclosure of any optional modules your server is using. The ServerRoot directive specifies where your web server configuration files and modules are kept. This server root directory is then used as a prefix to other directory entries.

ServerTokens OS
ServerRoot "/etc/httpd"

The Process ID file is /etc/httpd/run/httpd.pid. The /etc/httpd/run directory holds several PID files for various Apache supported processes.

Connection and request timing is handled by Timeout, KeepAlive, MaxKeepAliveRequests, and KeepAliveTimeout directives. Timeout is the time in seconds that the web server times out a send or receive request. KeepAlive allows persistent connections, several requests from a client on the same connection.

This is turned off by default. MaxKeepAliveRequests sets the maximum number of requests on a persistent connection. KeepAliveTimeout is the time that a given connection to a client is kept open to receive more requests from that client.

The Listen directive will bind the server to a specific port or IP address. By default, this is port 80. The Listen directive is defined in httpd.conf.

Listen 80

The User and Group directives specify what user and group the Apache Web server will be run as. This allows the Web server to run as a user other than root, providing greater security.  On Fedora the user and group are apache.

User apache
Group apache

Directive

Description

ServerToken url-path directory-filename

Enables access to documents stored in the local file system, other than under the document root.

BindAddress saddr

Binds the server to a specified IP address. For more control over the address and ports listened to, use the Listen directive. (Replaced in Apache 2.0 with the Listen directive.)

<IfDefine [!]parameter-name> ... </IfDefine>

The <IfDefine test> ... </IfDefine> section specifies conditional directives. Directives within an IfDefine section are processed if the test is true and are ignored otherwise. The test consists of a parameter name, which is true if the parameter is defined, and false if undefined. An ! placed before the parameter makes the test true if the parameter is undefined (not).

<IfModule [!]module-name> ... </IfModule>

The <IfModule test> ... </IfModule> section specifies conditional directives. The test checks to see if a module is compiled in Apache. It is true if present, and false if not. An !module-name is true if the module is not present.

Include filename

Inclusion of other configuration files.

KeepAlive on/off

Enables persistent connections, “Off” to disable.

KeepAliveTimeout seconds

The number of seconds Apache waits for another request before closing the connection.

MaxKeepAliveRequests seconds

Maximum number of request per connection.

Listen [IP address:]port number

Listens to more than one IP address or port. By default, it responds to requests on all IP interfaces, but only on the port given by the Port directive. Context: server config

ListenBacklog backlog

The maximum length of the queue of pending connections.

LoadFile filename filename ...

Links to the named object files or libraries when the server is started or restarted. Used to load additional code required for some module to work.

LoadModule module filename

Links in the object file or library filename and adds the module structure named module to the list of active modules.

LockFile filename

Path to the lockfile used when Apache is compiled.

PidFile filename

File holding server process ID

ServerRoot directory-filename

Sets the directory in which the server configuration, module, log, and error files reside.

TimeOut number

Sets the timeout in seconds for receiving GET requests, receipt of POST and PUT requests, and TCP packet transmissions acknowledgments.

Table 8-4: Global Directives

Apache modules are loaded from configuration files in the conf.modules.d directory and are read in using the Include directive.

Include conf.modules.d/*.conf

In the conf files in the conf.modules.d  directory, Modules are loaded with the LoadModule directives, one for each module.

LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule negotiation_module modules/mod_negotiation.so

Any additional configuration files are read in using the IncludeOptional directive at the end of the file, which references the conf.d directory. These include such files as welcome.conf for specifying a default welcome page.

IncludeOptional conf.d/*.conf

Multi-Processing Modules (MPM)

MPM prefork, worker, and event modules let you tailor your Apache web server to your workload demands (see Table 8-5). Default entries will already be set for a standard web server operating under a light load. You can modify these settings for different demands.

MPM Prefork Directives

Description

StartServers

Number of server processes to start

MinSpareServers

Minimum spare servers

MaxSpareServers

Maximum spare servers

ServerLimit

Maximum servers allowed

MaxRequestsWorkers

Maximum servers started

MaxConnectionsPerChild

Maximum requests allowed per server

MPM worker and event directives

StartServers

Number of server processes to start

MaxRequestsWorkers

Maximum number of clients

MinSpareThreads

Minimum spare threads

MaxSpareThreads

Minimum spare threads

ThreadsPerChild

Number of threads per server process

MaxConnectionsPerChild

Maximum number of requests for server

AsyncRequestWorkerFactor

Control number of connections per process (event only)

Table 8-5: MPM Prefork, Worker, and Event Directives

Three MPM modules are available to Unix and Linux systems: event, prefork, and worker. The prefork module is the simplest and supports one thread per process, which maintains compatibility with older systems and modules. The worker module supports multiple threads for each process, placing a much lower load on system resources. The new event module shares processing among threads and can be used on newer systems. It is based on the worker module. The modules share several of the same directives, such as MaxRequestPerChild.

The modules loaded are specified in the 00-mpm.conf file located in the /etc/httpd/conf.modules.d directory. Fedora currently uses the prefork module by default. Corresponding cgi modules are loaded automatically in the 01-cgi.conf file.

LoadModule mpm_prefork_module modules/mod_mpm_prefork.so

To load the worker or event modules, remove the comment character  (#) from its entry and make the prefork load module entry a comment. Check the MPM documentation pages for more details, such as:

https://httpd.apache.org/docs/2.4/mod/event.html
https://httpd.apache.org/docs/2.4/mpm.html

Apache runs a single parent process with as many child processes as are needed to handle requests. Configuration for MPM modules focuses on the number of processes that should be available. The prefork module will list server numbers, as a process is started for each server; the worker module will control threads since it uses threads for each process. The StartServer directive lists the number of server processes to start for both modules. This will normally be larger for the prefork than for the worker module.

For the prefork module you can set minimum and maximum settings for spare servers. MaxRequestsWorkers sets the maximum number of servers that can be started, and ServerLimit sets the number of servers allowed. The MaxConnectionsPerChild sets the maximum number of connections allowed for a server.

For the worker module, MaxRequestsWorkers also sets the maximum number of client threads, and ThreadsPerChild sets the number of threads for each server. MaxConnectionsPerChild limits the maximum number of requests for a server. Spare thread limits are also configured.

The event module is based on the worker module uses the same directives.  It adds an AsyncRequestWorkerFactor directive throttle the number of connections for a process.

Server Configuration

Certain directives are used to configure your server’s overall operations. These directives are placed midway in the httpd.conf configuration file, directly under the section labeled Server Settings  (see Table 8-6). Some directives require pathnames, whereas others only need to be turned on or off with the keywords on and off. The default httpd.conf file already contains these directives. Some are commented out with a preceding # symbol. You can activate a directive by removing its # sign. Many of the entries are preceded by comments explaining their purpose.

The following is an example of the ServerAdmin directive used to set the address where users can send mail for administrative issues. You replace the you@your.address entry with the address you want to use to receive system administration mail. By default, this is set to root@localhost.

# ServerAdmin: Your address, where problems should be e-mailed.
ServerAdmin root@localhost

The ServerName directive holds the hostname for your Web server. Specifying a hostname is important to avoid unnecessary DNS lookup failures that can hang your server. Notice the entry is commented with a preceding #. Simply remove the # and type your Web server’s hostname in place of new.host.name. If you are using a different port than 80, be sure to specify it attached to the host name, as in turtle.mytrek.com:80. Here is the original default entry:

# ServerName gives the name and port that the server uses to identify itself.
# This can often be determined automatically, but we recommend you specify
# it explicitly to prevent problems during startup.
#ServerName www.example.com:80

Directive

Description

AddModule module module ...

Apache 1.3: Enables use of modules compiled, but not in use (dropped in Apache 2.0).
Context: server config

Alias url-path directory-filename

Enables access to documents stored in the local file system, other than under the document root.

BindAddress saddr

Binds the server to a specified IP address. For more control over the address and ports listened to, use the Listen directive. (Replaced in Apache 2.0 with the Listen directive.)

DefaultLanguage MIME-lang

Specifies MIME-lang as the default file language.
Context: server config, virtual host, directory, .htaccess

DefaultType MIME-type

Default type for documents whose type cannot be determined by their MIME types mappings.

DocumentRoot directory-filename

The directory from which httpd serves files.
Default: DocumentRoot /usr/local/apache/htdocs
(/var/www/html on Red Hat systems)

Group unix-group

Sets the group for the server. The stand-alone server must be run initially as root. The recommendation is you set up a new group specifically for running the server.

HostNameLookups on | off | double

Enables DNS lookups so that hostnames can be logged. Double refers to double-reverse DNS.

LoadFile filename filename ...

Links to the named object files or libraries when the server is started or restarted. Used to load additional code required for some module to work.

Port number

If no Listen or BindAddress directives exist, a port directive sets the network port on which the server listens. Ports for a virtual host are set by the VirtualHost directive.

ServerAdmin e-mail-address

The e-mail address for the server administrator.

ServerAlias host1 host2 ...

Sets the alternate names for a host, for use with name-based virtual hosts.

ServerName fully qualified domain name

Sets the hostname of the server. This is used only when creating redirection URLs. If it is not specified, the server attempts to deduce it from its own IP address.

ServerPath pathname

Sets the legacy URL pathname for a host, for use with name-based virtual hosts.

ServerSignature Off | On | Email

Configures a trailing footer line under server-generated documents, such as error messages.

SetHandler handler-name

Forces all matching files to be passed through the handler given by handler-name.

User unix-userid

Specifies the user ID for the server. The stand-alone server must be run as root initially. You can use a username or a user ID number. The user should have no access to system files. The recommendation is for you to set up a new user and group specifically for running the server.

UserDir directory/filename

Sets the real directory in a user’s home directory to use when a request for a document for a user is received.

Redirect [ status ] url-path url

Maps an old URL into a new one.

ScoreBoardFile filename

Specifies the ScoreBoardFile file.

Table 8-6: Server Directives

A modified ServerName entry would look like this:

ServerName turtle.mytrek.com

When receiving URL requests for the server system, like those for local files on the system, the UseCanonicalName directive will use the ServerName to generate the host URL server name. When off, it will just use the name supplied by the client request. This can be confusing if the Web server is referenced by one name but uses another, like www.mytrek.com used to reference turtle.mytrek.com. UseCanonicalName set to on will overcome this problem, generating the correct local URL.

On Fedora systems, entries have already been made for the standard Web server installation using /var/www as your Web site directory. You can tailor your Web site to your own needs by changing the appropriate directives. The DocumentRoot directive determines the home directory for your Web pages.

DocumentRoot "/var/www/html"

The EnableSendfile and EnableMMAP directives (at the end of the httpd.conf file) enhance server performance. EnableSendfile allows the system to perform the transmission of files.  EnnableMMAP enables memory mapping for transmitted files should your system support it.

#EnableMMAP off
EnableSendfile on

Note: You can also configure Apache to operate as just a proxy and/or cache server. Default proxy and cache server directives are already included in the httpd.conf file. The ProxyRequests directive turns proxy activity on. Caching can be configured with directives like CacheRoot to specify the cache directory, CachSize for the cache size (500KB default), and CacheMaxExpire to set a time limit on unmodified documents.

Access Controls

With access control directive require you can control access to your website by remote users and hosts  (see Table 8-7).

Directive

Description

require user-authentication

Authenticates users that can access a given directory or site. Authentication can refer to all users (all), userids (user), groups (group), domain name (host), IP address (ip), and even an expression, HTTP method, or environment variable.

require host hosts

Determines hosts (domain names ) that can access a given directory.

require ip addresses

Determines hosts (IP addresses) that can access a given directory.

require all granted

Grant access to all hosts

require all denied

Deny access to all hosts

<Files filename> ... </Files>

Provides for access control by filename. Similar to the <Directory> directive and <Location> directive. <Files> sections are processed in the order they appear in the configuration file, after the <Directory> sections and .htaccess files are read, but before <Location> sections. <Files> can be nested inside <Directory> sections to restrict the portion of the file system to which they apply.

<FilesMatch regex> ... </FilesMatch>

Provides for access control by filename like the <Files> directive, but uses a regular expression.

<Limit method method ... > ... </Limit>

<Limit> and </Limit> specify a group of access control directives that apply only to the specified access methods, any valid HTTP method. Access control directives appearing outside a <Limit> directive apply to all access methods. Method names are GET, POST, PUT, DELETE, CONNECT, and OPTIONS.

<LimitExcept method method ... > ... </LimitExcept>

<LimitExcept> and </LimitExcept> specify a group of access control directives, which then apply to any HTTP access method not listed in the arguments.

<Location URL> ... </Location>

The <Location> directive provides for access control by URL. Similar to the <Directory> directive.

<LocationMatch regex> ... </LocationMatch>

Provides access control by URL, in an identical manner to <Location>, using a regular expression as an argument.

LimitRequestBody number

Limits the size of an HTTP request message body.

Table 8-7: Access Control Directives

With Apache 2.4, the require directive replaces the allow, order, deny, and satisfy directives used in Apache 2.2. It is implemented by the mod_authz_host module. Access can be granted or denied. The all term refers to all hosts.  The require directive can be used globally to control access to the entire site or placed within Directory directives to control access to individual directives. In the following example, all users are allowed access:

require all granted

The require directive performs authentication on users. Authentication can refer to all users (all), specific users (user), groups (group), the domain name of a host the users are on (host), IP address (ip) of a host, and even an expression (expr), HTTP method (method), or environment variable (env). In most cases, it is used to determine access by all users (all), or those from specified hosts (host or ip).

Directory-level Configuration

One of the most flexible aspects of Apache is its ability to configure individual directories. With the Directory directive, you can define a block of directives that apply only to a particular directory (see Table 8-8). Such a directive can be placed in the httpd.conf configuration file. You can also use an .htaccess file within a particular directory to hold configuration directives. Those directives are then applied only to that directory. The name .htaccess is set with the AccessFileName directive. You can change this if you want.

AccessFileName .htaccess

A Directory block begins with a <Directory pathname> directive, where pathname is the directory to be configured. The ending directive uses the same <> symbols, but with a slash preceding the word “Directory”: </Directory>. Directives placed within this block apply only to the specified directory. A restrictive default Directory directive is defined in the httpd.conf file.

<Directory />
    AllowOverride None
    Require all denied
</Directory>

Access is allowed to the Web server content at /var/www.

<Directory "/var/www ">
    AllowOverride None
     # Allow open access:
    Require all granted
</Directory>

Then the directory block is defined for the Web site directory, /var/www/html. This is the location for all the Web site files. The "Require all granted" directive will allow anyone to access the files.

<Directory "/var/www/html">
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

You can also set up directives for specific directories. The following example allows access to the mypics directory by requests from www.myvids.com.

<Directory /var/www/html/mypics>
Require host www.myvids.com
</Directory>

Directive

Description

AccessFileName filename filename

Default directory configuration filenames located within directories.

<Directory directory> ... </Directory>

<Directory> and </Directory> directives operate as tags that enclose a group of directives applying only to the named directory and subdirectories of that directory.

<DirectoryMatch regex> ... </DirectoryMatch>

<DirectoryMatch> and </DirectoryMatch> enclose a group of directives that apply only to the named directory. It operates the same as <Directory>, but takes a regular expression as an argument.

DirectoryIndex local-url local-url ...

Specifies the list of resources to look for when the client requests an index of the directory by specifying a / at the end of a directory name (usually index.html).

Options [+|-]option [+|-]option ...

Controls the server features available in a particular directory.
OPTIONS
None If set to None, none of the extra features are enabled.
All All options except for MultiViews. This is the default setting.
ExecCGI Execution of CGI scripts is permitted.
FollowSymLinks The server follows symbolic links in this directory.
Includes Server-side includes are permitted.
IncludesNOEXEC Server-side includes are permitted, but the #exec command and #include of CGI scripts are disabled.
Indexes Returns a formatted listing of the directory for directories with no DirectoryIndex.
MultiViews Content negotiated MultiViews are allowed.
SymLinksIfOwnerMatch The server follows only symbolic links for which the target file or directory is owned by the same user ID as the link.

AllowOverride override override ...

Directives that can be overridden by entries in an .htaccess file. All allows overrides, and none denies them.
Default: AllowOverride All
Context: directory

Table 8-8: Directory Directives

To deny access to the .htaccess files by Web clients, a Files block is defined with the access control directives "Require all denied", which denies access to all users. The Files directive references any file beginning with .ht (the period is quoted with a backslash). The </Files> entry ends the <Files> block.

<Files ~ ".ht*">
     Require all denied
</Files>

With the Options directive, you can enable certain features in a directory, such as the use of symbolic links, automatic indexing, execution of CGI scripts, and content negotiation. The default is the All option, which turns on all features except content negotiation (Multiviews). The following example enables automatic indexing (Indexes), symbolic links (FollowSymLinks), and content negotiation (Multiviews).

Options Indexes FollowSymLinks Multiviews

Configurations made by directives in main configuration files or in upper-level directories are inherited by lower-level directories. Directives for a particular directory held in .htaccess files and Directory blocks can be allowed to override those configurations. This capability can be controlled by the AllowOverride directive. With the all argument, .htaccess files can override any previous configurations. The none argument disallows overrides, effectively disabling the .htaccess file. You can further control the override of specific groups of directives. AuthConfig enables the use of authorization directives, FileInfo is for type directives, Indexes is for indexing directives, Limit is for access control directives, and Options is for the options directive.

AllowOverride all

When given a URL for a directory instead of an HTML file, and when no default web page is in the directory, Apache creates a page on the fly and displays it. This is usually only a listing of the different files in the directory. In effect, Apache indexes the items in the directory for you. You can set several options for generating and displaying such an index using IndexOptions. With FancyIndexing, web page items are displayed with icons and column headers that can be used to sort the listing. With VersionSort items are sorted alphabetically and numerically. NameWidth sets column width, with the * value setting the width as needed. Charset sets the character set, usually UTF-8. For a complete list of options see https://httpd.apache.org/docs/2.4/mod/mod_autoindex.html#indexoptions

IndexOptions FancyIndexing VersionSort NameWidth=* HTMLTable Charset=UTF-8

URL Pathnames

Certain directives can modify or complete pathname segments of a URL used to access your site. The pathname segment of the URL specifies a particular directory or Web page on your site. Directives enable you to alias or redirect pathnames, as well as to select a default Web page. With the Alias directive, you can let users access resources located in other parts of your system, on other file systems, or on other Web sites. An alias can use a URL for sites on the Internet, instead of a pathname for a directory on your system. With the Redirect directive, you can redirect a user to another site. These directives require that the alias_module be loaded.

Alias /mytrain /home/dylan/trainproj
Redirect /mycars http://www.myautos.com/mycars

If Apache is given only a directory to access, rather than a specific Web page, it looks for an index Web page located in that directory and displays it. The possible names for a default Web page are listed by the DirectoryIndex directive. The name usually used is index.html, but you can add others. The standard names are shown here. When Apache is given only a Web directory to access, it looks for and displays the index.html Web page located in it.

DirectoryIndex index.html index.shtml index.cgi

The DirectoryIndex directive is conditional on dir_module being loaded.

<IfModule dir_module
     DirectoryIndex index.html
</IfModule>

Apache also lets a user maintain Web pages located in a special subdirectory in the user’s home directory, rather than in the main Web site directory. Using a ~ followed by the username accesses this directory. The name of this directory is specified with the UserDir directive. The default name is public_html, as shown here. The site turtle.mytrek.com/~dylan accesses the directory turtle.mytrek.com/home/dylan/public_html on the host turtle.mytrek.com.

UserDir public_html

If you want, instead, to allow people to use a full pathname, then use a pathname reference. For example, for the user dylan, /usr/www would translate to a URL reference of /usr/www/dylan, where the HTML files would be located; /home/*/www would translate to /home/dylan/www, a www directory in the user dylan’s home directory.

UserDir /usr/www
UserDir /home/*/www

Userdir access is commented out by default in the standard configuration file. Usually, there are users like root that you want access denied to. With the disable and enable options, you can open access to certain users, while disabling access to others, as shown here:

UserDir disable root
UserDir disabled
UserDir enabled dylan chris justin

CGI Directory

Common Gateway Interface (CGI) files are programs that can be executed by Web browsers accessing your site. CGI files are usually initiated by Web pages that execute the program as part of the content they display  (see Table 8-9). Traditionally, CGI programs were placed in a directory called cgi-bin and could be executed only if they resided in such a special directory. Usually, only one cgi-bin directory exists per Web site. Distributions will normally set up a cgi-bin directory in the default Web server directory (/var/www/cgi-bin on Fedora). Here, you place any CGI programs that can be executed on your Web site. The ScriptAlias directive specifies an alias for your cgi-bin directory. Any Web pages or browsers can use the alias to reference this directory.

ScriptAlias /cgi-bin/ /var/www/cgi-bin/

Controls are then placed on the cgi-bin directory.

<Directory "/var/www/cgi-bin">
   AllowOverride None
   Options None
   Require all granted
</Directory>

Mime Types

When a browser accesses Web pages on a Web site, it is often accessing many different kinds of objects, including HTML files, picture or sound files, and script files. To display these objects correctly, the browser must have some indication of what kind of objects they are. A JPEG picture file is handled differently from a simple text file. The server provides this type information in the form of MIME types. MIME types are the same types used for sending attached files through Internet mailers, such as Pine. Each kind of object is associated with a given MIME type. Provided with the MIME type, the browser can correctly handle and display the object.

Directive

Description

Action action-type cgi-script

Adds an action, which activates cgi-script when action-type is triggered by the request.

AddHandler handler-name extension extension ...

Maps the filename extensions extension to the handler handler-name.

RemoveHandler extension extension ...

Removes handler associations for files with the given extensions. This allows .htaccess files in subdirectories to undo any associations inherited from parent directories or the server configuration files.

Script method cgi-script

Adds an action, which activates cgi-script when a file is requested using the method of method, which can be one of GET, POST, PUT, or DELETE.

ScriptAlias url-path directory-filename

Marks the target directory as containing CGI scripts.

ScriptInterpreterSource ‘registry’ or ‘script’

Finds the interpreter used to run CGI scripts. The default method is to use the interpreter pointed to by the #! line in the script.

Table 8-9: CGI Directives

The MIME protocol associates a certain type with files of a given extension. For example, files with a .jpg extension would have the MIME type image/jpeg. The TypesConfig directive holds the location of the mime.types file, which lists all the MIME types and their associated file extensions. (DefaultType no longer had an effect in Apache 2.4). AddType enables you to modify the mime.type types list without editing the MIME file.

TypesConfig /etc/mime.types

These directives require that the mime_module be loaded. They are dependent on the mime_module module.

<IfModule mime_module>

The AddDefaultCharset directive specifies the default character set.

AddDefaultCharset UTF-8

The mime magic module makes use of hints from a file's contents to determine its type. Hint definitions are listed in the /etc/httpd/conf/magic file, which has hints for animation, TeX, MS Word, XML, audio formats, and compressed files. 

<IfModule mod_mime_module>
     #   MIMEMagicFile /usr/share/magic.mime
     MIMEMagicFile conf/magic
</IfModule>

Other type directives are used to specify actions to be taken on certain documents. AddEncoding lets browsers decompress compressed files on the fly. AddHandler maps file extensions to actions, and AddLanguage enables you to specify the language for a document. The following example marks filenames with the .gz extension as gzip-encoded files and files with the .fr extension as French language files:

AddEncoding x-gzip .gz .tgz
AddLanguage fr .fr

A Web server can display and execute many different types of files and programs. Not all Web browsers are able to display all those files, though. Older browsers are the most limited. Some browsers, such as Lynx, are not designed to display even simple graphics. To allow a Web browser to display a page, the server negotiates with it to determine the type of files it can handle. To enable such negotiation, you need to enable the Multiviews option.

Option multiviews

Automatic Directory Indexing

When given a URL for a directory instead of an HTML file, and when no default Web page is in the directory, Apache creates a page on the fly and displays it. This is usually only a listing of the different files in the directory. In effect, Apache indexes the items in the directory for you. You can set several options for generating and displaying such an index. Indexing directives are listed in Table 8-10. If FancyIndexing is turned on, Web page items are displayed with icons and column headers that can be used to sort the listing.

FancyIndexing on

Icon directives tell Apache what icon to display for a certain type of file. The AddIconByType and AddIconByEncoding directives use MIME-type information to determine the file’s type and then associate the specified image with it. AddIcon uses the file’s extension to determine its type.With the IndexOptions directive, you can set different options for displaying a generated index. Options exist for setting the heights and widths of icons and filenames. The IconsAreLinks option makes icons part of filename anchors. The ScanHTMLTitles option reads the titles in HTML documents and uses those to display entries in the index listing instead of filenames. Various options exist for suppressing different index display features such as sorting, descriptions, and header/readme inserts.

Authentication

Your web server can also control access on a per-user or per-group basis to particular directories on your website. You can require various levels of authentication. Access can be limited to particular users and require passwords, or expanded to allow members of a group access. You can dispense with passwords altogether or set up an anonymous type of access, as used with FTP.

To apply authentication directives to a certain directory, you place those directives within either a Directory block or the directory’s .htaccess file. You use the require directive to determine what users can access the directory. You can list particular users or groups. The AuthName directive provides the authentication realm to the user, the name used to identify the particular set of resources accessed by this authentication process. The AuthType directive specifies the type of authentication, such as basic or digest. A require directive requires also AuthType, AuthName, and directives specifying the locations of group and user authentication files. In the following example, only the users george, robert, and mark are allowed access to the newpics directory:

<Directory /var/www/newpics
     AuthType Basic
     AuthName Newpics
     AuthUserFile /web/users
     AuthGroupFile /web/groups
     <Limit GET POST>
           require user george robert mark
     </Limit>
</Directory>

Directive

Description

AddDescription string file file ...

Sets the description to display for a file. Can be a file extension, partial filename, wildcard expression, or full filename. String is enclosed in double quotes (").

IndexOptions [+|-]option [+|-]option ...

Set options for directory indexing:
FancyIndexing, IconHeight, IconsAreLinks, IconWidth, NameWidth, ScanHTMLTitles, SuppressDescription.

ReadmeName filename

Specifies the name of the file to be appended to the end of the index listing.

AddIcon icon name name ...

Specifies the icon to display next to a file ending in name.

AddIconByEncoding icon MIME-encoding MIME-encoding ...

Specifies the icon to display next to files with MIME-encoding (FancyIndexing).

AddLanguage MIME-lang extension extension ...

Maps the given filename extensions to the specified content language.

FancyIndexing Boolean

Sets the FancyIndexing option for a directory. Boolean can be on or off.

DefaultIcon url

Specifies the icon to display for files when no specific icon is known (FancyIndexing).

HeaderName filename

Specifies the name of the file to be inserted at the top of the index listing (FancyIndexing).

Table 8-10: Indexing Directives

To set up anonymous access for a directory, place the Anonymous directive with the user anonymous as its argument in the directory’s Directory block or .htaccess file. You can also use the Anonymous directive to provide access to particular users without requiring passwords from them.

Apache maintains its own user and group authentication files specifying what users and groups are allowed access to which directories. These files are normally simple flat files, such as your system’s password and group files. They can become large, however, possibly slowing down authentication lookups. As an alternative, many sites have used database management files in place of these flat files. Database methods are then used to access the files, providing a faster response time. Apache has directives for specifying the authentication files, depending on the type of file you are using. The AuthUserfile and AuthGroupFile directives are used to specify the location of authentication files that have a standard flat file format.

The programs htdigest, htpasswd, and dbmmanage are tools provided with the Apache software package for creating and maintaining user authentication files, which are user password files listing users who have access to specific directories or resources on your website. The htdigest and htpasswd programs manage a simple flat file of user authentication records, whereas dbmmanage uses a more complex database management format. If your user list is extensive, you may want to use a database file for fast lookups. htdigest takes as its arguments the authentication file, the realm, and the username, creating or updating the user entry. htpasswd can also employ encryption on the password. dbmmanage has an extensive set of options to add, delete, and update user entries. A variety of different database formats is used to set up such files. Three common ones are Berkeley DB2, NDBM, and GNU GBDM. dbmmanage looks for the system libraries for these formats in that order. Be careful to be consistent in using the same format for your authentication files.

User Web sub-sites in user home directories: UserDir

Apache supports user-based sites on servers using html files located in user home directories. These are users set up on the Apache server host machine. You use the ~ with the user name to select that user's sub-site. The following will access the user robert's Web sub-site on the www.turtle.com site.

www.turtle.com/~robert

In the user's home directory a public_html directory is set up which holds the html files for that user's site. The public_html directory has to have executable permission enabled to allow access by all users, a+x. Access will also have to be allowed by all users to the user home directory.

chmod a+x public_html
chmod a+x /home/robert

The user robert's site would be located at /home/robert/public_html.

For Apache to support sites in user home directories, you need to enable the UserDir directive in the /etc/httpd/conf/httpd.conf file. UserDir is disabled by default. A commented out enabled version is provided below its entry. You can simply remove or comment out the UserDir disabled entry, then remove the comment symbol (#) from the enabled entry. The UserDir directive is enabled by listing the name to be used for the user Web directories as an option. The default directory is public_html.

UserDir  public_html

If SELinux is enabled, you will also have to allow access by the Web server to the user Web files. These are created as local user files with a user security context. You will have to change the security type for the security context of the user Web file to httpd_sys_content_t. This is the same context type used for Web html file in /var/www. For a persistent change use semanage and the fcontext directive with the -a and -t options. Then run restorecon. Add (/.*) regular expression to the directory name, and quote it, if you already have some Web files in that directory. If the directory is empty, you don't need it.

semanage  fcontext -a -t httpd_sys_content_t "/home/robert/public_html(/.*)"
restorecon  -R /home/robert/public_html

Should you want just a temporary change, you can use chcon. This change will be lost though if your system relabels or restores contexts.

chcon -Rt httpd_sys_content_t  public_html

The httpd.conf file also includes commented code you can use to secure user Web directories by making them read only. A Directory directive on the public_html directory uses Limit directives with order and allow options to control access.

Log Files

Apache maintains logs of all requests by users to your Web site. By default, these logs include records using the Common Log Format (CLF). The record for each request takes up a line composed of several fields: host, identity check, authenticated user (for logins), the date, the request line submitted by the client, the status sent to the client, and the size of the object sent in bytes  (see Table 8-11).

Directive

Description

CustomLog file-pipe format-or-nickname

Creates a new log file with the specified format.

ErrorDocument error-code document

Redirects to a local or external URL to handle the problem/error.

ErrorLog filename|syslog[:facility]

The file on which the server logs errors.

LogFormat format [nickname]

Sets the format of the default log file named by the TransferLog directive.
Default: LogFormat "%h %l %u %t \"%r\" %s %b"

TransferLog file-pipe

Adds a log file in the format defined by the most recent LogFormat directive or Common Log Format if default is specified.

LogLevel level

Adjusts the verbosity of the messages recorded in the error logs.

Table 8-11: Logging Directives

Webalizer

Reports on Web logs can be generated using the Webalizer tool. Webalizer will display information on your Web site usage. When you run the webalizer command, usage reports will be placed in the /var/www/html/usage directory. Access the index page to display a page with links to monthly reports, file:/var/www/html/usage/index.html. Report configuration is specified in the /etc/webalizer.conf file. Previous summaries are kept in the /etc/webalizer.history file. Webalizer Apache configuration is located in the webalizer.conf file in the conf.d directory, /etc/httpd/conf.d/webalizer.conf.

Error log and warning level

The httpd.conf file holds configuration directives for configuring your log files.  The ErrorLog directive specifies the log file used for saving error messages.  Each virtual host can have its own error log.

ErrorLog  "logs/error_log"

The LogLevel directive controls the number of messages that will be saved in the error log. Options range through debug, info, notice, warn, error, crit, alert, emerg; from larger to smaller amounts. The default is warn.

LogLevel warn

Formatting Logs

Using the LogFormat and CustomLog directives, you can format your log record to add more fields with varying levels of detail. They are dependent on the loading of log_config_module.

<IfModule log_config_module>

These directives use a format string consisting of field specifiers to determine the fields to record in a log record. You add whatever fields you want and in any order. A field specifier consists of a percent (%) symbol followed by an identifying character. For example, %h is the field specifier for a remote host, %b for the size in bytes, and %s for the status  (see Table 8-12). See the documentation for the mod_log_config module for a complete listing.

You should quote fields whose contents may take up more than one word. The quotes themselves must be quoted with a backslash to be included in the format string. The following example is the Common Log Format implemented as a LogFormat directive:

LogFormat "%h %l %u %t \"%r\" %>s %b" common

Certain field specifiers in the log format can be qualified to record specific information . The %i specifier records header lines in requests the server receives. The reference for the specific header line to record is placed within braces between the % and the field specifier. For example, User-agent is the header line that indicates the browser software used in the request. To record User-agent header information, use the conversion specifier %{User-agent}i.

LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

To maintain compatibility with NCSA servers, Apache originally implemented AgentLog and RefererLog directives to record User-agent and Referer headers. These have since been replaced by qualified %i field specifiers used for the LogFormat and CustomLog directives. A Referer header records link information from clients, detecting who may have links to your site. The following is an NCSA-compliant log format, combined:

LogFormat "%h %l %u %t \"%r\" %s %b\"%{Referer}i\" \"%{User-agent}i\"" combined

Should you want to log the number of bytes per request, you can load the logio_module and use the %I and %O field specifiers for input and output.

<IfModule logio_module>
     # You need to enable mod_logio.c to use %I and %O
     LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
</IfModule>

Field Specifier

Description

%a

Remote IP address

%A

Local IP address

%b

Bytes sent, excluding HTTP headers

%{variable}e

The contents of the environment variable

%{variable}i

Header line in requests sent to server

%f

Filename

%h

Remote host

%l

Remote logname (from identd, if supplied)

%m

The request method

%P

The process ID of the child that serviced the request

%r

First line of request

%s

Status

%t

Time, in Common Log Format time format (standard English format)

%u

Remote user (from auth; may be bogus if return status [%s] is 401)

%U

The URL path requested

%v

The canonical ServerName of the server serving the request

Table 8-12: Apache Log Field Specifiers

Note: The Apache Web server can also provide detailed reports on server activity and configuration, letting you display this information to remote servers. The Location directive server-info will display the configuration details of your Web server, and the server-status directive will show Web processes. The pages server-info and server-status will display the reports, as in http://localhost/server-info. Use the ExtendedStatus directive to enable detailed reports.

Generating and Managing Log Files

Instead of maintaining one large log file, you can create several log files using the CustomLog or TransferLog directive. This is helpful for virtual hosts where you may want to maintain a separate log file for each host. You use the LogFormat directive to define a default format for log records. The TransferLog directive then uses this default as its format when creating a new log file. CustomLog combines both operations, enabling you to create a new file and to define a format for it.

LogFormat "%h %l %u %t \"%r\" %s %b"  myprojlog
# Create a new log file using the myprojlog format
TransferLog myprojlog
# Create a new log file called mypicslog using its own format
CustomLog mypicslog "%h %l %u %t \"%r\" %s %b"

You can first define a format with LogFormat and then use CustomLog to specify the log file and format used.  By default, the httpd.conf file defines the combined format and then uses this format to save logs in the logs/access_log file.

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
CustomLog logs/access_log combined

Using the previous example, the mypicslog format is first defined and then saved in the logs/picslog file.

LogFormat "%h %l %u %t \"%r\" %s %b"  mypicslog
CustomLog log/picslog  mypicslog

Apache provides two utilities for processing and managing log files: logresolve resolves IP addresses in your log file to hostnames; rotatelogs rotates log files without having to kill the server. You can specify the rotation time.

Virtual Hosting on Apache

Virtual hosting allows the Apache Web server to host multiple Web sites as part of its own. In effect, the server can act as several servers, each hosted Web site appearing separate to outside users. Apache supports both IP address–based and name-based virtual hosting. IP address–based virtual hosts use valid registered IP addresses, whereas name-based virtual hosts use fully qualified domain addresses. These domain addresses are provided by the host header from the requesting browser. The server can then determine the correct virtual host to use on the basis of the domain name alone. Note that SSL servers require IP virtual hosting. See https://httpd.apache.org for more information.

IP based virtual hosting

In the IP address–based virtual hosting method, your server must have a different IP address for each virtual host. The IP address you use is already set up to reference your system. Network system administration operations can set up your machine to support several IP addresses. Your machine could have separate physical network connections for each one, or a particular connection could be configured to listen for several IP addresses at once. In effect, any of the IP addresses can access your system.

You can configure Apache to run a separate daemon for each virtual host, separately listening for each IP address, or you can have a single daemon running that listens for requests for all the virtual hosts. To set up a single daemon to manage all virtual hosts, use VirtualHost directives. To set up a separate daemon for each host, also use the Listen directive.

Name-Based Virtual Hosting

With name-based virtual hosting, you can support any number of virtual hosts using no additional IP addresses. With only a single IP address for your machine, you can still support an unlimited number of virtual hosts. Such a capability is made possible by the HTTP/1.1 protocol, which lets a server identify the name by which it is being accessed. This method requires the client, the remote user, to use a browser that supports the HTTP/1.1 protocol, as current browsers do. A browser using such a protocol can send a host header specifying the particular host to use on a machine.

ServerName turtle.mytrek.com

<VirtualHost 192.168.1.5:80>
ServerName www.mypics.com
ServerAdmin webmaster@mail.mypics.com
DocumentRoot /var/www/mypics/html
ErrorLog /var/www/mypics/logs/error_log
...
</VirtualHost>

<VirtualHost 192.168.1.5:80>
ServerName www.myproj.org
ServerAdmin webmaster@mail.myproj.org
DocumentRoot /var/www/myproj/html
ErrorLog /var/www/myproj/logs/error_log
....
</VirtualHost>

To implement name-based virtual hosting, use a VirtualHost directive for each host and a to specify the IP address you want to use for the virtual hosts (NameVirtualHost directive has been deprecated with Apache 2.4). If your system has only one IP address, you need to use that address. Within the VirtualHost directives, you use the ServerName directive to specify the domain name you want to use for that host. Using ServerName to specify the domain name is important to avoid a DNS lookup. A DNS lookup failure disables the virtual host. The VirtualHost directives each take the IP address as their argument. You use Apache directives within the VirtualHost blocks to configure each host separately. Name-based virtual hosting uses the domain name address specified in a host header to determine the virtual host to use. If no such information exists, the first host is used as the default. The following example implements two name-based virtual hosts. Here, www.mypics.com and www.myproj.org are implemented as name-based virtual hosts instead of IP-based hosts:

If your system has only one IP address, implementing virtual hosts prevents access to your main server with that address. You could no longer use your main server as a Web server directly; you could use it only indirectly to manage your virtual host. You could configure a virtual host to manage your main server’s Web pages. You would then use your main server to support a set of virtual hosts that would function as Web sites, rather than the main server operating as one site directly. If your machine has two or more IP addresses, you can use one for the main server and the other for your virtual hosts. You can even mix IP-based virtual hosts and name-based virtual hosts on your server. You can also use separate IP addresses to support different sets of virtual hosts. You can further have several domain addresses access the same virtual host. To do so, place a ServerAlias directive listing the domain names within the selected VirtualHost block.

ServerAlias www.mypics.com www.greatpics.com

Dynamic Virtual Hosting

If you have implemented many virtual hosts on your server that have the same configuration, you can use a technique called dynamic virtual hosting to have these virtual hosts generated dynamically. The code for implementing your virtual hosts becomes much smaller, and as a result, your server accesses them faster. Adding yet more virtual hosts becomes a simple matter of creating appropriate directories and adding entries for them in the DNS server.

To make dynamic virtual hosting work, the server uses commands in the mod_vhost_alias module  to rewrite both the server name and the document root to those of the appropriate virtual server. Dynamic virtual hosting can be either name-based or IP-based. In either case, you have to set the UseCanonicalName directive in such a way as to allow the server to use the virtual hostname instead of the server’s own name. For name-based hosting, you simply turn off UseCanonicalName. This allows your server to obtain the hostname from the host header of the user request. For IP-based hosting, you set the UseCanonicalName directive to DNS. This allows the server to look up the host in the DNS server.

UseCanonicalName Off
UseCanonicalName DNS

You then have to enable the server to locate the different document root directories and CGI bin directories for your various virtual hosts. You use the VirtualDocumentRoot directive to specify the template for virtual hosts’ directories. For example, if you place the different host directories in the /var/www/hosts directory, you can then set the VirtualDocumentRoot directive accordingly.

VirtualDocumentRoot /var/www/hosts/%0/html

The %0 will be replaced with the virtual host’s name when that virtual host is accessed. It is important that you create the dynamic virtual host’s directory using that host’s name. For example, for a dynamic virtual host called www.mygolf.org, you first create a directory named /var/www/hosts/www.mygolf.org, then create subdirectories for the document root and CGI programs, as in /var/www/hosts/www.mygolf.org/html. For the CGI directory, use the VirtualScriptAlias directive to specify the CGI subdirectory you use.

VirtualScriptAlias /var/www/hosts/%0/cgi-bin

A simple example of name-based dynamic virtual hosting directives follows:

UseCanonicalName Off
VirtualDocumentRoot /var/www/hosts/%0/html
VirtualScriptAlias /var/www/hosts/%0/cgi-bin

A request for www.mygolf.com/html/mypage evaluates to

/var/www/hosts/www.mygolf.com/html/mypage

A simple example of dynamic virtual hosting is shown here:

UseCanonicalName Off

<VirtualHost 192.168.1.5>
ServerName www.mygolf.com
ServerAdmin webmaster@mail.mygolf.com
VirtualDocumentRoot /var/www/hosts/%0/html
VirtualScriptAlias /var/www/hosts/%0/cgi-bin
...
</VirtualHost>

To implement IP-based dynamic virtual hosting instead, set the UseCanonicalName to DNS instead of Off.

UseCanonicalName DNS
VirtualDocumentRoot /var/www/hosts/%0/html
VirtualScriptAlias /var/www/hosts/%0/cgi-bin

 Interpolated Strings

The mod_vhost_alias module supports various interpolated strings, each beginning with a % symbol and followed by a number. As you have seen, %0 references the entire web address. %1 references only the first segment, %2 references the second, %-1 references the last part, and %2+ references from the second part on. For example, to use only the second part of a web address for the directory name, use the following directives:

VirtualDocumentRoot /var/www/hosts/%2/html
VirtualScriptAlias /var/www/hosts/%2/cgi-bin

In this case, a request made for www.mygolf.com/html/mypage uses only the second part of the web address. This would be “mygolf” in www.mygolf.com, and would evaluate to

/var/www/hosts/mygolf/html/mypage

If you used %2+ instead, as in /var/www/hosts/%2/html, the request for www.mygolf.com/html/mypage would evaluate to

/var/www/hosts/mygolf.com/html/mypage

The same method works for IP addresses, where %1 references the first IP address segment, %2 references the second, and so on.

 Logs for Virtual Hosts

One drawback of dynamic virtual hosting is that you can set up only one log for all your hosts. However, you can create your own shell program to simply cut out the entries for the different hosts in that log.

LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
CustomLog logs/access_log vcommon

Note: Apache also supports IP address–based virtual hosting. Your server must have a different IP address for each virtual host. Your machine can have separate physical network connections for each one. You can configure Apache to run a separate daemon for each virtual host, separately listening for each IP address, or you can have a single daemon running that listens for requests for all the virtual hosts. To set up a single daemon to manage all virtual hosts, use VirtualHost directives. To set up a separate daemon for each host, also use the Listen directive.

Apache Instances

Apache also supports the implementation of additional Web server instances on the same Linux system. An instance is, in effect, a separate Web server with its own copy of the /etc/httpd/conf/httpd.conf file. See the comments in the instance.conf file in the /usr/share/doc/httpd directory for details on how to create and maintain an Apache instance. See also the "Instantiated services" section of the httpd.service man file, man httpd.service.

Decide on a name for your instance. It can be any name. Use the instance.conf file in the /usr/share/doc/httpd/ directory as the configuration file for your instance. Copy that file, giving it the name of your instance to your /etc/httpd/conf/ directory. For example, if you want the name of your instance to be myhttpd1, you use the following command.

sudo cp /usr/share/doc/httpd/instance.conf /etc/httpd/conf/myhttpd1.conf

Make any custom changes to the file that you want.

To enable and run the new instance, you use the httpd@.service file, add in the name of your instance.

sudo systemctl enable httpd@myhttpd1
sudo systemctl start httpd@myhttpd1

This file assigns the name of your instance to the HTTP_INSTANCE variable, which is then used by the instance's .conf file to reference separate configuration and runtime directories and files. In this example, the mythttd1.conf file would use the HTTP_INSTANCE variable to set up a separate runtime directory at /run/httpd/instance-myhttpd1. Separate runtime, pid, and log files are set up this way.

DefaultRuntimeDir /run/httpd/instance-${HTTPD_INSTANCE}
PidFile /run/httpd/instance-${HTTPD_INSTANCE}.pid
ErrorLog "logs/${HTTPD_INSTANCE}_error_log"
CustomLog "logs/${HTTPD_INSTANCE}_access_log" combined

To run simultaneously with other instances, you would also have to designate a separate port to listen on.

Instances will share many of their configuration files with the main httpd service. Should you make changes to this httpd configuration files, and need to reload it, you may also want to reload the instance services. You can have this done automatically by creating a drop-in file for the instance with the lines.

[Unit]

ReloadPropagetedFrom=httpd.service

Use the systemctl edit command and the httpd@.service file with  the name of the instance to create the drop-in file.

sudo systemctl edit httpd@myhttpd1.service

This creates an override.conf file in the /etc/systemd/system/httpd@myhttpd.service.d directory.

Server Side Includes

Server-side includes (SSIs) are designed to provide a much more refined control of your Web site content, namely the Web pages themselves. Server-side includes are Apache directives placed within particular Web pages as part of the page’s HTML code. You can configure your Apache Web server to look for SSI directives in particular Web pages and execute them. First, you have to use the Options directive with the include option to allow SSI directives.

Options Includes

You need to instruct the server to parse particular Web pages. The easiest way to enable parsing is to instruct Apache to parse HTML files with specified extensions. Usually, the extension .shtml is used for Web pages that have SSI directories. In fact, in the default Apache configuration files, you can find the following entry to enable parsing for SSI directives in HTML files. The AddType directive here adds the .shtml type as an HTML type of file, and the AddOutputFilter directive specifies that .shtml files are to be parsed:

# To use server-parsed HTML files
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

Instead of creating a separate type of file, you can use the XBitHack directive to have Apache parse any executable file for SSI directives. In other words, any file with execute permission will be parsed for SSI directives.

SSI directives operate much like statements in a programming language. You can define variables, create loops, and use tests to select alternate directives. An SSI directive consists of an element followed by attributes that can be assigned values. The syntax for an SSI directive is shown here:

<!--#element attribute=value ... -->

You can think of an element as operating much like a command in a programming language and attributes as its arguments. For example, to assign a value to a variable, you use the set element with the variable assignment as its attribute. The if directive displays any following text on the given Web page. The if directive takes as its attribute expr, which is assigned the expression to test. The test is able to compare two strings using standard comparison operators such as <=, !=, or ==. Variables used in the test are evaluated with the $ operator.

<!--#set myvar="Goodbye" -->
<!--#if expr=="$myvar = Hello" -->

Other helpful SSI elements are exec, which executes CGI programs, or shell commands, which read the contents of a file into the Web page and also execute CGI files. The echo element displays values such as the date, the document’s name, and the page’s URL. With the config element, you can configure certain values, such as the date or file size.

PHP

PHP (PHP: Hypertext Preprocessor) is a scripting language designed for use in Web pages. PHP-enabled pages allow you to create dynamic Web pages that can perform tasks instead of just displaying data. PHP is an official project of the Apache Software Foundation. You can find out more about PHP at www.php.net.

Unlike CGI programs, which are executed separately from a Web page, PHP commands are embedded as tags within the page itself, much as SSI commands are. PHP support to interpret and execute these commands is provided directly by the Web server. This embedded support is enabled in Apache with the mod_php module (/etc/httpd/conf.d/php.conf configuration file). Instead of having to separately construct programs to be invoked and run outside the Web server, with PHP, such commands are embedded within a Web page and run by the Web server. The Web server maintains complete control at all times whenever tasks are being performed. It is possible, however, to implement PHP in a CGI mode, where PHP pages are constructed as separate programs, invoked by a Web page much as a Perl-based CGP program is.

PHP has flexible and powerful programming capabilities on the same level as C and Perl. As in those languages, you can create control structures such as if statements and loops. In addition, PHP has capabilities specifically suited to Web page tasks. PHP can interact directly with databases such as Oracle, MySQL, and IBM DB2. It can easily interact with all the standard protocols, such as IMAP, LDAP, HTTP, and POP3. It even has text processing abilities such as interpreting regular expressions and displaying XML documents. There are also extensions for searches, compression tools like gzip, and language translations. PHP supports a massive collection of possible operations. Check its Web site for a complete listing, as well as online manuals and tutorials.

Web Server Security: SSL

Web server security deals with two different tasks: protecting your Web server from unauthorized access, and providing security for transactions carried out between a Web browser client and your Web server. To protect your server from unauthorized access, you use a proxy server such as Squid. Squid is a GNU proxy server often used with Apache on Linux systems. Apache itself has several modules that provide security capabilities. These include mod_access for mandatory controls; mod_auth, mod_auth_db, mod_auth_digest, and mod_auth_dbm, which provide authentication support; and mod_auth_anon for anonymous FTP-like logging (see previous sections on access control and authentication).

To secure transmissions, you need to perform three tasks. You have to verify identities, check the integrity of the data, and ensure the privacy of the transmission. To verify the identities of the hosts participating in the transmission, you perform authentication procedures. To check the integrity of the data, you add digital signatures containing a digest value for the data. The digest value is a value that uniquely represents the data. Finally, to secure the privacy of the transmission, you encrypt it. Transactions between a browser and your server can then be encrypted, with the browser and your server alone able to decrypt the transmissions. The protocol most often used to implement secure transmissions with Linux Apache Web servers is the Secure Sockets Layer (SSL) protocol, which was originally developed by Netscape for secure transactions on the Web.

Like the Secure Shell (SSH) and the GNU Privacy Guard, SSL uses a form of public- and private-key encryption for authentication. Data is encrypted with the public key but can be decrypted only with the private key. Once the data is authenticated, an agreed-upon cipher is used to encrypt it. Digital signatures encrypt an MD5 digest value for data to ensure integrity. Authentication is carried out with the use of certificates of authority. Certificates identify the different parties in a secure transmission, verifying that they are who they say they are. A Web server will have a certificate verifying its identity, verifying that it is the server it claims to be. The browser contacting the server will also have a certificate identifying who it is. These certificates are, in turn, both signed by a certificate authority, verifying that they are valid certificates. A certificate authority is an independent entity that both parties trust.

A certificate contains the public key of the particular server or browser it is given to, along with the digital signature of the certificate authority and identity information such as the name of the user or company running the server or browser. The effectiveness of a certificate depends directly on the reliability of the certificate authority issuing it. To run a secure Web server on the Internet, you should obtain a certificate from a noted certificate authority such as VeriSign. A commercial vendor can do this for you. Many established companies already maintain their own certificate authority, securing transmissions within their company networks. An SSL session is set up using a handshake sequence in which the server and browser are authenticated by exchanging certificates, a cipher is agreed upon to encrypt the transmissions, and the kind of digest integrity check is chosen. There is also a choice in the kind of public key encryption used for authentication, either RSA or DSA. For each session, a unique session key is set up that the browser and server use.

A free open-source version of SSL called OpenSSL is available for use with Apache (see https://www.openssl.org/). It is based on SSLeay from Eric A. Young and Tim J. Hudson. The mod_ssl project provides an SSL module with patches you can use to update your Apache Web server to incorporate SSL. mod_ssl is free for both commercial and noncommercial use under an Apache-style license.

The mod_ssl implementation of SSL provides an alternate access to your Web server using a different port (443) and a different protocol, https. In effect, you have both an SSL server and a non-secure version. To access the secure SSL version, you use the protocol https instead of http for the Web server’s URL address. For example, to access the SSL version for the Web server running at www.mytrek.com, you would use the protocol https in its URL, as shown here:

https://www.mytrek.com

Install the mod_ssl package to install the mod_ssl module. You can configure mod_ssl using a number of configuration directives in the Apache configuration file, /etc/httpd/conf.d/ssl.conf. On Fedora, the default configuration file installed with Apache will load the ssl.conf file along with other module configuration files in the /etc/httpd/conf.d directory. Check the online documentation for mod_ssl at https://httpd.apache.org/docs/2.4/mod/mod_ssl.html for a detailed reference listing all the directives. There are global, server-based, and directory-based directives available.

In the Fedora ssl.conf file, the following code will load the SSL module:

LoadModule ssl_module     modules/mod_ssl.so

Several default directives are implemented such as the location of SSL key directories and the port that the SSL version of the server will listen on (443).

Listen 443 https

Others are commented out. You can enable them by removing the preceding # symbol, setting your own options. The SSL version for your Apache Web server is set up in the ssl.conf file as a virtual host, beginning with a virtual host directive block for port 443:

<VirtualHost _default_:443>

Within this block, SSL is enabled using the SSLEngine and SSLProtocol directives.

#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.

SSLEngine on
#   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv3 access by default:
SSLProtocol all -SSLv3

The SSLCipherSuite directive lists allowable ciphers.

SSLCipherSuite PROFILE=SYSTEM

Several SSL directives that will specify SSL certificates and encryption keys. SSL works with Transport Layer Security (TLS) to provide secure transmissions.  Certificates will be located in the /etc/pki/tls/certs directory, the TSL certificate directory.  The server key will be located in the TSL private directory holds the public and private keys used in authentication encryption.

#  Server Certificate:
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
#  Server Private Key:
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

#  Certificate Authority (CA):
#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt

The mod_ssl installation will provide you with a demonstration certificate called snakeoil that you can use to test your SSL configuration. When you have an official certificate, you can install it with the make certificate command.

Access controls are then placed on certain kinds of files and on the cgi-bin directory which contains executable files. The +StdEnvVars options applies all SLL variables.  

<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
</Files>

<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>

A CustomLog directive specifies the location, ssl_request_log, and the format for SSL messages.

CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

NGINX Web Server

The NGINX Web server is fast becoming a key support server for the Apache Web server, providing a reverse proxy to allow Apache to better handle high load demands. NGINX has an event-based asynchronous design that lets it handle requests at the same time using very little memory, instead of discretely threading requests as Apache does. This approach makes for a very fast Web server, though one that is not easily customized. Apache's easy modular design still make it easier to deploy. Often NGINX is used as a front end processor for an Apache server, handling a very large number of request, and then sending them on to the Apache server. You can find out more about NGINX at https://nginx.org, with documentation at https://nginx.org/en/docs/.

You can install NGINX with the nginx package. Configuration is located in the /etc/nginx directory. NGINX has the main configuration files in the /etc/nginx directory, and default site configuration files in the default.d directory. Sample default files have the extension .default, such as nginx.conf.default.

The configuration files are very simple, with an /etc/nginx/nginx.conf file as the main configuration file for the NGINX server, and several supporting configuration files, as well as an additional conf.d configuration directory. The format for commands uses a block structure, encased in braces. In the nginx.conf file, an http block sets the global settings for the Web server, with include directives for configuration files and the sites-enabled server files. You can set up a Web server with very few directives and blocks. It is advised that you create a new file for the website configuration, to better tailor it to your needs. There is a server block for each port a server listens on, and location blocks to access website files. The http block in the /etc/nginx/nginx.conf file is shown here. The block includes basic, log file location, and gzip directives. Website configuration files are read in from the /etc/nginx/conf.d directory, The server block in the shows directives for a default server configuration.

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 2048;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;

    server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  _;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        location / {
        }

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
     }   
}         

9. News and Database Services

Newsgroup servers are more rare, used for setting up newsgroups for local networks or for supporting the Internet's Usenet News service. Database servers are becoming more common for managing large collections of data on local networks as well as for Internet services.

News Servers

News servers provide Internet users with Usenet news services. They have their own TCP/IP protocol, the Network News Transfer Protocol (NNTP). On most Linux systems, the InterNetNews (INN) news server provides news services (https://www.isc.org/). In addition, servers exist that provide better access to Internet resources.

The InterNetNews (INN) news server accesses Usenet newsfeeds, providing news clients on your network with the full range of newsgroups and their articles. Newsgroup articles are transferred using NNTP, and servers that support this protocol are known as NNTP servers. INN was written by Rich Salz and is currently maintained and supported by the Internet Software Consortium (ISC). You can download current versions from its website at https://www.isc.org/. INN is also included with most Linux distributions. The documentation directory for INN in /usr/share/doc contains extensive samples. The primary program for INN is the innd daemon.

There are two versions of INN, a smaller INN used for local networks, and a much more complex INN2 used for large networks. INN also includes several support programs to provide maintenance and crash recovery and to perform statistical analysis on server performance and usage. cleanfeed implements spam protection, and innreport generates INN reports based on logs. INN also features a very strong filter system for screening unwanted articles.

Note: Leafnode is an NNTP news server designed for small networks that may have slow connections to the Internet. You can obtain the Leafnode software package along with documentation from its website at www.leafnode.org.

Database Servers

Several fully functional database servers are provided for Fedora: MariaDB, MySQL Derby, and PostgreSQL. MariaDB is derived from MySQL but is a more advanced and fully open-sourced. It is the default MySQL type database for Fedora. MariaDB is supported and developed by the original MySQL developers. The original MySQL is owned by Oracle and features commercial versions. You can still install the older non-commercial version of MySQL if you wish.

As noted in Chapter 2, you can install the PostgreSQL server using the server role databaseserver. You use rolectl to install (deploy) the server. You can configure and install multiple instances of the server.

Derby is a JAVA based database developed by Apache. SQLite is a simple and fast database server requiring no configuration and implementing the database on a single disk file. This chapter will cover how to set up and manage a MySQL database and will offer a brief introduction to PostgreSQL. You can learn more about these products through the sites listed in Table 9-1.

In addition, Fedora also supports document based non-SQL servers such as MongoDB and Hadoop.  MongoDB is a document-based database that can be quickly searched.  Hadoop is an Apache project for accessing very large data sets distributed across a network.

Database

Resource

MariaDB

https://mariadb.org/

MySQL

https://www.mysql.com

Derby

https://db.apache.org/derby/

MongoDB

https://www.mongodb.org

Hadoop

https://hadoop.apache.org/

PostgreSQL

https://www.postgresql.org

sqlite

www.sqlite.org

 Table 9-1: Database Resources

Relational Database Structure

MariaDB and PostgreSQL both use a relational database structure. Essentially, this means data is placed in tables, with identifier fields used to relate the data to entries in other tables. Each row in the table is a record, each with a unique identifier, like a record number. The connections between records in different tables are implemented by special tables that associate the unique identifiers from records in one table with those of another. Relational database theory and implementation are subjects beyond the scope of this chapter.

A simple, single-table database has no need for a unique identifier. A simple address book listing names and addresses is an example of a single-table database. However, most databases access complex information of different types, related in various ways. Instead of having large records with repeated information, you divide the data in different tables, each holding the unique instance of the data. This way, data is not repeated; you have only one table that holds a single record for person’s name, rather than repeating that person’s name each time the data references him or her. The relational organization then takes on the task of relating one piece of data to another. This way, you can store a great deal of information using relatively small database files.

Though there are many ways to implement a relational database, a simple rule of thumb is to organize data into tables where you have a unique instance of each item of data. Each record is given a unique identifier, usually a number. To associate the records in one table with another, you create tables that associate their identifiers.

The SQL query language is the language used by most relational database management systems (RDBMSs), including both MySQL and PostgreSQL. Though many RDBMSs use administrative tools to manage databases, on Linux MySQL and PostgreSQL, you still have to use the SQL commands directly. The following command will create the database:

CREATE DATABASE myphotos

Before performing any operations on a database, you first access it with the USE command.

USE myphotos

The tables are created using the CREATE TABLE command; the fields for each table are listed within parentheses following the table name. For each field, you need to specify a name, data type, and other options, such as whether it can have a null value or not.

CREATE TABLE names (
    personid INT(5) UNSIGNED NOT NULL,
    name VARCHAR(20) NOT NULL,
    street VARCHAR(30) NOT NULL,
    phone CHAR(8)
     );

MariaDB (MySQL)

MariaDB is designed to be fully compatible with MySQL databases. Like MySQL, MariaDB is structured on a client/server model with a server daemon (mysqld) filling requests from client programs. MariaDB is designed for speed, reliability, and ease of use. It is meant to be a fast database management system for large databases and, at the same time, a reliable one, suitable for intensive use. To create databases, you use the standard SQL language. User access can be controlled by assigning privileges.

On Fedora, you can install the MariaDB server and client packages, along with numerous configuration packages for certain services like Postfix, Exim, and Apache . Packages to install are mariadb and mariadb-server.

MariaDB MySQL is managed by systemd using the /lib/systemd/system/mariadb.service unit file. The mysqld.service file is simply a link to the mariadb.service file.  For the service file, you should create a version of it in the /etc/systemd/system directory, which includes the original version. As noted in the comments for the mariadb.service file, you would create a version in /etc/systemd/system that includes the system version in /lib/systemd/system. Then you add a Service section with added options, as shown here.

/etc/systemd/system/mariadb.service

.include /lib/systemd/system/mysqld.service
[Service]
  LimitNOFILE=10000

Alternatively you can create a .conf in the /etc/systemd/system/mariadb.service.d directory.

The mariadb.service file is shown here.

mariadb.service

[Unit]
Description=MariaDB 10.0 database server
Documentation=man:mysqld(8)
Documentation=https://mariadb.com/kb/en/library/systemd/
After=network.target

[Install]
WantedBy=multi-user.target
Alias=mysql.service
Alias=mysqld.service

[Service]
Type=notify
User=mysql
Group=mysql
ExecStartPre=/usr/libexec/mysql-check-socket
ExecStartPre=/usr/libexec/mysql-prepare-db-dir %n
ExecStart=/usr/bin/mysqld_safe --basedir=/usr $MYSQLD_OPTS $_WSREP_NEW_CLUSTER
ExecStartPre=/usr/libexec/mysql-check-upgrade

PrivateNetwork=false

KillMode=process
KillSignal=SIGTERM
SendSIGKILL=no
Restart=on-abort
RestartSec=5s
UMask=007

TimeoutSec=300
PrivateTmp=true

MariaDB Configuration

The MariaDB supports different configuration files, one for global settings, and other in the /etc/etc/my.cnf.d directory for client and server-specific settings, and an optional file for user-customized settings. MariaDB has the same configuration files as MySQL, with added mariadb sections that are read only by MariaDB. This ensures capability with MySQL databases.

The /etc/my.cnf configuration file is used for global settings applied to both clients and servers. The /etc/my.cnf file provides information such as the data directory (/var/lib/mysql) and log files (/var/log/mysql) locations, as well as the server base directory (/var/lib).

The /etc/my.cnf.d/mariadb-server.cnf file is used for server settings only. Client only settings are located in /etc/my.cnf.d/mariadb-clients.cnf.

The .my.cnf file allows users to customize their access to MySQL. It is located in a user’s home directory. Note that this is a dot file.

You can access the MariaDB documentation at https://mariadb.com/kb/en/library/documentation/.

Upon installing MariaDB you have to first enable it with systemctl before you can start the server.

sudo systemctl enable mariadb

You can then start the mysql server.

sudo systemctl start mysql

 Global Configuration:/etc/my.cnf

MariaDB (MySQL) specifies options according to different groups, usually the names of server tools. The options are arranged in segments. The segment name is placed within brackets, and options applied to it follow. A basic /etc/my.cnf file is shown here:

 [mysqld]
datadir=/var/lib/mysql
socket = /var/run/mysqld/mysql.sock
symbolic-links=0
log-error=/var/log/mysqld.log
pid-file = /var/run/mysqld/mysqld.pid
!includedir /etc/my.cnf.d

Global options are listed in the /etc/my.cnf file. Options are set up according to groups that control different behaviors of the database service: mysqld for the daemon and safe_mysqld for the startup script. The datadir directory, /var/lib/mysql, is where your database files will be placed.

Server and client configuration is read from cnf files in the /etc/my.cnf.d directory. The client.cnf file has a client segment that will set up options to be sent to clients, such as the port and socket to use to access the MySQL database. There is also a section, named client-mariadb, for MariaDB options.

 [client]
port=3306

Place options that should only be read by the server in the mariadb-server.cnf file. MariaDB also has a mariadb section for MariaDB only options.

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mariadb/maridb.log
pid-file = /var/run/mariadb/mariadb.pid

The mysql-clients.cnf file has sections where you can place options for different MariaDB tools such as mysqladmin, mysqlcheck, and mysqlshow. 

To see what options are currently set for both client and server, you run mysqld directly with the --help option.

/usr/libexec/mysqld --help

User Configuration: .my.cnf

Users who access the database server will have their own configuration file in their home directory: .my.cnf. Here the user can specify connection options such as the password used to access the database and the connection timeouts.

 [client]
password=mypassword

[mysql]
no-auto-rehash
set-variable = connect_timeout=2

[mysql-hotcopy]
interactive-timeout

MariaDB Tools

MariaDB provides a variety of tools (as shown in Table 9-2), including server, client, and administrative tools. Backups can be handled with the mysldump command. The mysqlshow command will display a database, just as issuing the SQL command SELECT *.* does, and mysqlimport can import text files, just like LOAD INFILE.

MariaDB Management with mysql and mysqladmin

To manage your MariaDB database, you use mysql as the root user. The mysql client starts up the MySQL monitor. As the root user, you can enter administrative commands to create databases and database tables, add or remove entries, as well as carry out standard client tasks such as displaying data.

Log in as the root user and open a terminal window. First be sure that the mysql server has started. You can use the systemctl command and cockpit. Be sure that you have enabled the mariadb server (systemctl) after its installation.

sudo systemclt start mysql

Then enter the mysql command. This will start a monitor shell with a mysql> prompt. Be sure to end your commands with a semicolon; otherwise, the monitor will provide an indented arrow prompt waiting for added arguments. In the monitor, the semicolon, not the enter key, ends commands.

Command

Description

mysqld

MySQL (MariaDB) server

mysql

MySQL (MariadDB) client

mysqladmin

Creates and administers databases

mysqldump

Database backup

mysqlimport

Imports text files

mysqlshow

Displays databases

 Table 9-2: MySQL Commands

If you have not set up a root user password yet, you can do so with the mysqladmin command, as shown here.

mysqladmin -u root password 'mypassword'

If you have set up a MySQL (MariaDB) root user, you can use the -u root with the -p option. You will be prompted for a password.

# mysql -u root -p
mysql>

Once the mysql client has started, you can use the status command to check the status of your server and show databases to list current databases.

mysql> status;
mysql> show databases;

Initially, two databases set up by MariaDB for its own management are displayed: mysql and test. The mysql database holds MariaDB user information, and the test database is used to test the server.

 PostgreSQL

PostgreSQL is based on the POSTGRESQL database management system, though it uses SQL as its query language. POSTGRESQL is a next-generation research prototype developed at the University of California, Berkeley. You can find more information on it from the PostgreSQL website at https://www.postgresql.org. PostgreSQL is an open source project, developed under the GPL license.

PostgreSQL is often used to provide database support for Internet servers with heavy demands, such as web servers. With a few simple commands, you can create relational database tables. Use the createuser command to create a PostgreSQL user that you can then log in to the server with. You can then create a database with the createdb command and construct relational tables using the create table directive. With an insert command, you can add records and then view them with the select command. Access to the server by remote users is controlled by entries in the pg_hba.conf file located in PostgreSQL directory, usually /var/lib/pgsql.

Currently, the PostgreSQL server is also packaged in the Fedora Database Server Role. Using the database server role, you can quickly install the PostgreSQL database server with just a few prompts. Configuration is handled automatically by the server role software.  Use Cockpit to install it on a Fedora server.

Part 3:  Shared Resources

10. Print Services

11. Network File Systems and Network Information Service: NFS and NIS

12. Samba

13. Distributed Network File Systems

10. Print Services

Print services have become an integrated part of every Linux system. They allow you to use any printer on your system or network.

Once treated as devices attached to a system directly, printers are now treated as network resources managed by print servers. In the case of a single printer attached directly to a system, the networking features become transparent and the printer appears as just one more device. On the other hand, you could easily use a print server's networking capability to let several systems use the same printer. Although printer installation is almost automatic on most Linux distributions, it helps to understand the underlying process. Printing sites and resources are listed in Table 10-1.

The Common UNIX Printing System (CUPS) provides printing services. It is freely available under the GNU Public License. Though it is now included with most distributions, you can also download the most recent source-code version of CUPS from https://www.cups.org/, which provides detailed documentation on installing and managing printers. CUPS is based on the Internet Printing Protocol (IPP), which was designed to establish a printing standard for the Internet (for more information, see www.pwg.org/ipp). Whereas the older line printer (LPD) based printing systems focused primarily on line printers, an IPP-based system provides networking, PostScript, and web support. CUPS works like an Internet server and employs a configuration setup much like that of the Apache web server. Its network support lets clients directly access printers on remote servers, without having to configure the printers themselves. Configuration needs to be maintained only on the print servers.

Resource

Description

https://www.cups.org

Common Unix Printing System

https://www.pwg.org/ipp

Internet Printing Protocol

 Table 10-1: Print Resources

Printer Services: CUPS

CUPS is the primary print server for most Linux distributions. GNOME provides integrated support for CUPS, allowing GNOME-based applications to directly access CUPS printers.

Once you have installed your printers and configured your print server, you can print and manage your print queue using print clients. There are a variety of printer clients available for the CUPS server, GNOME print manager, the CUPS configuration tool, and various line printing tools like lpq and lpc. These are described in further detail later in this chapter. The CUPS configuration tool is a web-based configuration tool that can also manage printers and print jobs (open your browser and enter the URL http://localhost:631). A web page is displayed with entries for managing jobs, managing printers, and administrative tasks. Select the Manage Jobs entry to remove or reorder jobs you have submitted.

CUPS is managed by systemd using an on demand socket implementation with cups.service, cups.socket, and cups.path files. In addition, a special printer.target unit detects when a printer is connected to your system. The cups.service file runs the CUPS server, /usr/sbin/cupsd (ExecStart). It is run when the printer.target is activated, which happens when a user connects a printer (WantedBy). The cups.socket unit file has CUPS listen for request at the CUPS socket, /var/run/cups/cups.sock (ListenStream).  In effect, CUPS runs like the old inetd daemons, activated only when requested.  The cups.path unit sets up CUPS print directories at /var/spool/cups (PathExistsGlob) when the system starts up (WantedBy=multi-user.target).

cups.service

[Unit]
Description=CUPS Scheduler
Documentation=man:cupsd(8)
After=network.target ypbind.service

[Service]
ExecStart=/usr/sbin/cupsd -l
Type=notify

[Install]
Also=cups.socket cups.path
WantedBy=printer.target

cups.socket

[Unit]
Description=CUPS Scheduler
PartOf=org.cups.cupsd.service

[Socket]
ListenStream=/var/run/cups/cups.sock

[Install]
WantedBy=sockets.target

cups.path

[Unit]
Description=CUPS Scheduler
PartOf=org.cups.cupsd.service

[Path]
PathExistsGlob=/var/spool/cups/d*

[Install]
WantedBy=multi-user.target

Note: Line Printer, Next Generation (LPRng) was the traditional print server for Linux and UNIX systems, but it has since been dropped from Fedora. You can find out more about LPRng at https://sourceforge.net/projects/lprng.

Driverless Printing

Most newer printer models support driverless printing. Instead of installing a driver, the printer supports a driverless driver. You can print to any of these printers without first downloading and installing a driver for them. The printers are automatically detected through DNS Service Discovery (DNS-SD). The CUPS Web configuration interface, system-config-printer, GNOME printers, and lpadmin already support driverless printing.

CUPS uses the driverless utility to detect available driverless printers and to generate PPD configuration files for them. The drivers may not be as complete in features as their official drivers, but will print. Currently printers compatible with IPP Anywhere and Apple Raster supported printers can make use of driverless drivers, usually newer printers. GNOME Printer, system-config-printer, and the CUP Web interface all use the driverless tool to detect and configure driverless printers. See the man page for driverless for more information.

Conflicts may occur with the cups-browsed daemon, which was an earlier effort to implement a version of driverless printing, and is still useful for printers that do not support driverless printing. You may have to set option in the /etc/cups/cups-browsed.conf file to support driverless printing. You need to set the  OnlyUnsupportedByCUPS and CreateIPPPrinterQueues options.

Printer Devices and Configuration

Before you can use any printer, you first have to install it on a Linux system on your network. A local printer is installed directly on your own system. This involves creating an entry for the printer in a printer configuration file that defines the kind of printer it is, along with other features such as the device file and spool directory it uses. On CUPS, the printer configuration file is /etc/cups/printers.conf. Installing a printer is fairly simple: determine which device file to use for the printer and the configuration entries for it.

Printer Device Files

Linux dynamically creates the device names for printers that are installed. For parallel printers, the device names will be lp0, lp1, and lp2, depending on how many parallel printers are connected. The number used in these names corresponds to a parallel port on your PC; lp0 references the LPT1 parallel port and lp1 references the LPT2 parallel port. Serial printers will use serial ports, referenced by the device files like ttyS0, ttyS1, ttyS2, and so on. USB-connected printers will have a Hardware Abstract Layer (HAL) device connection. HAL is designed for removable devices that can easily be attached to other connections and still be recognized.

 Spool Directories

When your system prints a file, it makes use of special directories called spool directories. A print job is a file to be printed. When you send a file to a printer, a copy of it is made and placed in a spool directory set up for that printer. The location of the spool directory is obtained from the printer’s entry in its configuration file. On Linux, the spool directory is located at /var/spool/cups under a directory with the name of the printer. For example, the spool directory for the myepson printer would be located at /var/spool/cups/myepson. The spool directory contains several files for managing print jobs. Some files use the name of the printer as their extension. For example, the myepson printer has the files control.myepson, which provides printer queue control, and active.myepson for the active print job, as well as log.myepson, which is the log file.

Server script

You can start, stop, and restart CUPS using the systemctl command or cockpit. When you make changes or install printers, be sure to restart CUPS to have your changes take effect. You can use the following command:

sudo systemctl restart cups

Printer Install and Configuration

There are several tools available for installing CUPS printers. The easiest method is to use the GNOME Printers tool (System Settings).  You can also use the older Fedora system-config-printer tool. Alternatively, you can use the CUPS Web browser-based configuration tools, included with the CUPS software. Finally, you can just edit the CUPS printer configuration files directly.

Automatic printer detection

When you attach a local printer to your system for the first time, the GNOME 3 printers tool automatically detects the printer and installs the appropriate driver. The printer is then listed in both the GNOME 3 printer tool and in the older system-config-printer.  If the detection fails, you can use the GNOME 3 printer tool, accessible from System Settings, to set up your printer.

Printer URI (Universal Resource Identifier)

Printers can be local or remote. Both are referenced using Universal Resource Identifiers (URI). URIs support both network protocols used to communicate with remote printers, and device connections used to reference local printers.

Remote printers are referenced by the protocol used to communicate with it, like ipp for the Internet Printing Protocol used for Unix network printers, smb for the Samba protocol used for Windows network printers, and lpd for the older LPRng Unix servers. Their URIs are similar to a Web URL, indicating the network address of the system the printer is connected to.

ipp://mytsuff.com/printers/queue1
smb://guest@lizard/myhp

For attached local printers, the URI will use the device connection and the device name. The usb: prefix is used for USB printers, parallel: for older printers connected to a parallel port, serial: for printers connected to a serial port, and scsi: for SCSI connected printers. For a locally attached USB printer, the URI would be something like this.

usb://Canon/S330

GNOME Printers: GNOME Settings

The GNOME Printers tool is accessible from the GNOME Settings | Devices | Printers tab. It lists installed printers, letting you configure them and access their job queues (see Figure 10-1). If no printers are detected, an Add New Printer button is displayed on the tab, which you can use to detect your printer. To detect additional printers, you can click the Add button. The Printers tab will list entries for detected and configured printers. A printer entry displays the printer name, model, status, a jobs button with the number of jobs, and a configuration button (gear icon). the jobs button to open a dialog listing active jobs for this printer (see Figure 10-1). For each job entry there are buttons to the right to pause or remove the job. 

Figure 10-1: GNOME 3 Printers tool

To configure a printer, click the configure button (gear icon) to display a menu with entries for the printer's options, details, default, and removal. Choosing the "Use Printer by Default", makes it your default printer. The "Remove Printer" entry remove the printer configuration from your system. The "Printer Details" entry opens a dialog with printer's details, such as the name, location, address, and driver. There are buttons for selecting a driver from a search, database, or a PPD file. Use these if the right driver has not been detected. Clicking on the "Printing Options" entry open the printer’s options dialog. You can configure printer features, such as page setup, image quality, and color. The Advanced tab lets you set specialized options, such as contrast, ink type, and saturation.

On the Settings Printers tab, you can Add button to open the Add Printer dialog, which lists printers attached to your system. They are detected automatically. If you know the address of a printer on your network, you can enter it in the search box at the bottom to have it detected and displayed.

system-config-printer: Printing

To edit a printer configuration or to add a remote printer, you can use system-config-printer, accessible as Printing (Sundry | Print Settings). This utility enables you to select the appropriate driver for your printer, as well as set print options such as paper size and print resolutions. You can configure a printer connected directly to your local computer or a printer on a remote system on your network. A printer configuration window is displayed showing icons for installed printers. As you add printers, icons for them are displayed in the Printer configuration window (see Figure 10-2).

Figure 10-2: system-config-printer tool: multiple printers

To see the printer settings such as printer and job options, access controls, and policies, double-click on the printer icon or right-click and select Properties. The Printer Properties window opens up with five tabs: Settings, Policies, Access Control, Printer Options, and Job Options (see Figure 10-3).

Figure 10-3: Printer properties window

CUPS Web Configuration Interface

One of the easiest ways to configure and install printers with CUPS is to use the CUPS configuration Web interface, a web browser–based tool. The CUPS configuration interface is a web-based tool that can also manage printers and print jobs. A web page is displayed with tabs for managing jobs and printers and performing administrative tasks.

You access the CUPS configuration tool using the localhost address and specifying port 631. Enter the following URL into your web browser:

http://localhost:631

Entering the localhost:631 URL in your Web browser opens the Home screen for the CUPS Web interface. There are tabs for various sections, as well as links for specialized tasks like adding printers or obtaining help (see Figure 10-4). Tabs include Administration, Classes, Help, Jobs, and Printers. You can manage and add printers on the Administration tab. The Printers tab will list installed printers with buttons for accessing their print queues, printer options, and job options, among others. The Jobs tab lists your print jobs and lets you manage them.

Figure 10-4: CUPS Web-based Configuration: Home tab

When you try to make any changes for the first time during the session, you will first be asked to enter the administrator’s username (your user name) and password (your user password), just as you would for the sudo command.

The Administration tab displays segments for Printers, Classes, Jobs, and the Server). The server section is where you allow printer sharing. Buttons allow you to view logs and change settings.

With the CUPS configuration tool, you install a printer on CUPS through a series of Web pages, each of which requests different information. To install a printer, click the Add Printer button either on the Home page or the Administration page. You first specify the protocol. On the next screen, you enter a URI to use for the printer.  For a local printer, this is the protocol and the hostname. A page is displayed where you enter the printer name and location.  A Sharing entry lets you choose to share the printer. The location is the host to which the printer is connected. The procedure is similar to system-config-printer. Subsequent pages will prompt you to enter the make and model of the printer, which you select from available listings. You can also load a PPD driver file instead if you have one. Click the Add Printer button when read. On the following page, you then set default options for your printer, like paper size and type, color, print quality, and resolution.

Remote Printers

Most newer printers support driverless printing. Available remote printers are detected automatically, and driverless configurations generated by CUPS. To manually search for a remote printer that is attached to a Windows system or another Linux system running CUPS, you specify its location, using special URL protocols. For another CUPS printer on a remote host, the protocol used is ipp, for Internet Printing Protocol, whereas for a Windows printer, it would be smb. Older Unix or Linux systems using LPRng would use the lpd protocol. Be sure your firewall is configured to allow access to remote printers.

Be sure your firewall is configured to allow access to remote printers. On the Trusted Services tab in system-config-firewall (Sundry | Firewall), be sure that the Samba and IPP services are checked. Samba allows access for Windows printers, and IPP allows access for Internet Printer Protocol printers usually found on other Linux systems. There will be entries for the Samba client and server, as well as IPP client and server.

To access an SMB shared remote printer, you need to install Samba and have the Server Message Block services enabled using the smb and nmb daemons. The Samba service should be enabled by default. If not, you can enable it using the systemctl command. Open a terminal window (Utilities| Terminal), and enter a sudo systemctl command for the smb and nmb servers with the enable command.

sudo systemctl enable nmb
sudo systemctl enable smbd

Configuring Remote Printers with system-config-printer

You can use system-config-printer to manually set up a remote printer on Linux, UNIX, or Windows networks. When you add a new printer or edit one, the New Printer/Select Connection dialog will list possible remote connection types. When you select a remote connection entry, a pane will be displayed where you can enter configuration information. The location is specified using special URI protocols. For another CUPS printer on a remote host, the protocol used is ipp, for Internet Printing Protocol, whereas for a Windows printer, it would be smb. Older UNIX or Linux systems using LPRng would use the lpd protocol

Configuring Remote Printers with CUPS Web-based Configuration

To use the CUPS Web-based configuration tool to install a remote printer, you specify the remote printer network protocol on the initial Add Printer page. You can choose from Windows, Internet Printing Protocol (other UNIX or Linux systems), Apple and HP JetDirect connected printers and the older LPD line printers. If a network printer is connected currently, it may be listed in the Discovered Network Printers list.

Configuring remote printers manually

In the cupsd.conf file, for a remote printer, the DeviceURI entry, instead of listing the device, will have an Internet address, along with its protocol. For example, a remote printer on a CUPS server (ipp) would be indicated as shown here (a Windows printer would use an smb protocol):

DeviceURI ipp://mystuff.com/printers/queue1

For a Windows printer, you first need to install, configure, and run Samba. (CUPS uses Samba to access Windows printers.) When you install the Windows printer on CUPS, you specify its location using the URL protocol smb. The user allowed to log in to the printer is entered before the hostname and separated from it by an @ sign. On most configurations, this is the guest user. The location entry for a Windows printer called myhp attached to a Windows host named lizard is shown here. It's Samba share reference would be //lizard/myhp:

DeviceURI smb://guest@lizard/myhp

To enable CUPS on Samba, you also have to set the printing option in the /etc/samba/smb.conf file to cups, as shown here:

printing = cups
printcap name = cups

CUPS Configuration files

CUPS configuration  files are placed in the /etc/cups directory. These files are listed in Table 10-2. The classes.conf, printers.conf, and client.conf files can be managed by the web interface. The printers.conf file contains the configuration information for the different printers you have installed. Any of these files can be edited manually if you wish.

cupsd.conf

The CUPS server is configured with the cupsd.conf file located in /etc/cups. You must edit configuration options manually; the server is not configured with the web interface. Your installation of CUPS installs a commented version of the cupsd.conf file with each option listed, though most options will be commented out. Commented lines are preceded with a # symbol. Each option is documented in detail. The server configuration uses an Apache web server syntax consisting of a set of directives. As with Apache, several of these directives can group other directives into blocks.

Filename

Description

classes.conf

Contains configurations for different local printer classes

client.conf

Lists specific options for specified clients

cupsd.conf

Configures the CUPS server, cupsd

printers.conf

Contains printer configurations for available local printers

cups-files.conf

File and directories used by CUPS

cups-browsed.conf

Access to remote and local printers

subscriptions.conf

Subscription controls for printer and print job information

 Table 10-2: CUPS Configuration Files

For a detailed explanation of cupsd.conf directives check the CUPS documentation for cupsd.conf. You can also reference this documentation from the Help page | References link on the CUPS browser-based administration tool, http://localhost:631.

https://www.cups.org/documentation.html

The cupsd.conf file begins with setting the log level to warn for warning.

LogLevel warn

The Listen directives are sets the machine and socket on which to receive connections. These are set by default to the local machine, localhost port 631. If you are using a dedicated network interface for connecting to a local network, you would add the network card's IP address, allowing access from machines on your network.

# Only listen for connections from the local machine.
Listen localhost:631
Listen /var/run/cups/cups.sock

Browsing directives allow your local printers to be detected on your network, enabling them to be shared. For shared printing, the Browsing directive is set to on (it is set to Off by default). A BrowseOrder of allow, deny will deny all browse transmissions, then first check the BrowseAllow directives for exceptions. A reverse order (deny, allow) does the opposite, accepting all browse transmissions, and then first check for those denied by BrowseDeny directives. The default cupsd.conf file has a BrowseOrder allow, deny directive followed by a BrowseAllow directive which is set to all. To limit this to a particular network, use the IP address of the network instead of all. The BrowseLocalProtocols lists the network protocols to use for advertising the printers on a local network. The BrowseAddress directive will make your local printers available as shared printers on the specified network. It is set to @LOCAL to allow access on your local network. You can add other BrowseAddress directives to allow access by other networks.

# Show shared printers on the local network.
Browsing On
BrowseOrder allow,deny
BrowseAllow all
BrowseLocalProtocols dnssd
BrowseAddress @LOCAL

CUPS supports both Basic and Digest forms of authentication, specified in the AuthType directive. Basic authentication uses a user and password. For example, to use the web interface, you are prompted to enter the root user and the root user password. Digest authentication makes use of user and password information kept in the CUPS /etc/cups/passwd.md5 file, using MD5 versions of a user and password for authentication. In addition, CUPS also supports a BasicDigest and Negotiate authentication. BasicDigest will use the CUPS md5 password file for basic authentication. Negotiate will use Kerberos authentication. The default authentication type is set using the DefaultAuthType directive, set to Basic.

# Default authentication type, when authentication is required...
DefaultAuthType Basic

Location Directives

Certain directives allow you to place access controls on specific locations. These can be printers or resources, such as the administrative tool or the spool directories. Location controls are implemented with the Location directive. There are several Location directives that control access. The first controls access to the server root directory, /. The Order allow, deny entry activates restrictions on access by remote systems. If there are no following Allow or Deny entries then the default is to deny all. There is an implied Allow localhost with the Order allow, deny directive, always giving access to the local machine. In effect, access here is denied to all system, allowing access only by the local system.

# Restrict access to the server...
<Location />
  Order allow,deny
</Location>

Another Location directive is used to restrict administrative access, the /admin resource, adding a requirement for encryption. The Order allow,deny directive denies access to all systems, except for the local machine.

# Restrict access to the admin pages...
<Location /admin>
  Order allow,deny
</Location>

Allow from and Deny from directives can permit or deny access from specific hosts and networks. If you wanted to just allow access to a particular machine, you would use an Allow from directive with the machine's IP address. CUPS also uses @LOCAL to indicate your local network, and IF(name) for a particular network interface (name is the device name of the interface) used to access a network. Should you want to allow administrative access by all other systems on your local network, you can add the Allow from @LOCAL. If you add an Allow directive, you also have to explicitly add the Allow localhost to ensure access by your local machine.

# Restrict access to the admin pages...
<Location /admin>
  Allow from localhost
  Allow from @LOCAL
  Order allow,deny
</Location>

The following entry would allow access from a particular machine.

  Allow From 192.168.0.5

The next location directive restricts access to the CUPS configuration files, /admin/conf.  The AuthType default directive refers to the default set by DefaultAuthType. The Require user directive references the SystemGroup directive, @SYSTEM (defined in the cups-files.conf file). Only users from that group are allowed access.

# Restrict access to configuration files...
<Location /admin/conf>
  AuthType Default
  Require user @SYSTEM
  Order allow,deny
</Location>

Default Operation Policy: Limit Directives

A default operation policy is then defined for access to basic administration, printer, print job, and owner operations. The default operation policy section begins with the <Policy default> directive. Limit directives are used to implement the directives for each kind of operation. Job operations covers tasks like sending a document, restarting a job, suspending a job, and restarting a job. Administrative tasks include modifying a printer configuration, deleting a printer, managing printer classes, and setting the default printer. Printer operations govern tasks like pausing a printer, enable or disable a printer, and shutting down a printer. The owner operations consist of just canceling a job and authenticating access to a job. Subscriptions are defined in the /etc/cups/subscriptions.conf file.

See the CUPS documentation on managing operations policies for more details.

https://www.cups.org/documentation.php/doc/policies.html

On all the default Limit directives, access is allowed only by the local machine (localhost), Order allow,deny.

The policy section begins with access controls for user and job information. The default for JobPrivateAccess limits access to owner, system, and access control lists. JobPrivateValues specifies values made private, such as the job name, originating host, and originating user.  SubscriptionPrivateAccess and SubscriptionPrivateValues specify access for subscription attributes such notifications of printer events like job completed or job stopped.

Both the administrative and printer Limit directives are set to the AuthType default and limited to access by administrative users, Require user @SYSTEM. The administrative directive is shown here.

  # All administration operations require an administrator to authenticate...
  <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default CUPS-Get-Devices>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>

Both the job related and owner Limit directives require either owner or administrative authentication, Require user @OWNER @SYSTEM. The Owner Limit directive is shown here.

  # Only the owner or an administrator can cancel or authenticate a job...
  <Limit Cancel-Job CUPS-Authenticate-Job>
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>

For all other tasks, <Limit All>, access is restricted to the local machine (localhost).

  <Limit All>
   Order deny,allow
  </Limit>

The AuthClass directive can be used within a Limit directive to specify the printer class allowed access. The System class includes the root, sys, and system users.

An authenticated set of policy directives follows the default policy, with similar entries and an added Limit directive to create and print jobs.

  <Limit Create-Job Print-Job Print-URI Validate-Job>
    AuthType Default
    Order deny,allow
  </Limit>

cupsctl

You can use the cupsctl command to modify your cupsd.conf file, rather than editing the file directly. Check the cupsctl Man page for details. The cupsctl command with no options will display current settings.

cupstctl

The changes you can make with this command are limited turning off remote administration or disabling shared printing. The major options you can set are:

remote-admin   Enable or disable remote administration

remote-any   Enable or disable remote printing

remote-printers   Enable or disable the display of remote printers

share-printers   Enable or disable sharing of local printers with other systems

printers.conf

Configured information for a printer will be stored in the /etc/cups/printers.conf file. You can examine this file directly, even making changes. Here is an example of a printer configuration entry. The DeviceURI entry specifies the device used, in this case, a USB printer. It is currently idle, with no jobs.  The OpPolicy entry specifies the policy defined in the cupsd.conf file to be used for this printer.

# Printer configuration file for CUPS
# Written by cupsd
<Printer mycannon>
UUID urn:uuid:72f4abc6-9afe-35f6-47e3-35ae26e3fdc1
Info Cannon S330
Location
MakeModel Canon S300 - CUPS+Gutenprint v5.2.9 Simplified
DeviceURI usb://Canon/S330
State Idle
StateTime 1166554036
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>

subscriptions.conf

Configured information for printer and job information is located in the /etc/cups/subscriptions.conf file.  Those receiving the information are specified by the SubscriptionPrivateAccess and SubscriptionPrivateValues directives in the policy section of the cupd.conf file. The Events directive specifies notifications of events to be sent, events such as job-completed, printer-stopped, and server-started. The Owner directive lists the users for this subscription. LeaseDuration is the time the subscription remains valid (0 value is the life of the print job or forever). Interval is the time between notifications. Recipient is the recipient URI for the notification. In the following example it is dbus://  (your desktop).

A sample subscriptions.conf file is shown here:

# Subscription configuration file for CUPS v2.2.6
# Written by cupsd on 2013-03-13 14:13
NextSubscriptionId 31
<Subscription 29>
Events printer-state-changed printer-restarted printer-shutdown printer-stopped printer-added printer-deleted job-state-changed job-created job-completed job-stopped
Owner richard
Recipient dbus://
LeaseDuration 3600
Interval 0
ExpirationTime 1529777935
NextEventId 1
</Subscription>

cups-files.conf

The files and directories that CUPS uses to manage print jobs can be configured in the /etc/cups/cups-files.conf file. The ErrorLog directive specified the CUPS error log output, which is sent to the system journal.

ErrorLog  journal

The SystemGroup directive defines the users  referenced by @SYSTEM in cupsd.conf.

SystemGroup sys root wheel

cups-browsed.conf

The cups-browsed.conf file configures the cups-browsed daemon, used for browsing remote and  local printers.  The BrowseRemoteProtocoals defines the protocols to use.  

BrowseRemoteProtocols  dnssd cups

The BrowseAllow directive can be used to restrict browsing to specified servers or networks.

BrowseAllow 192.168.1.0/24

The CreateIPPPritnerQueues directive allows the detection of non-CUPS IPP printers.

CUPS Command Line Print Clients

Once a print job is placed on a print queue, you can use any of several print clients to manage the printing jobs on your printer or printers, such as Klpq, the GNOME Print Manager, and the CUPS Printer Configuration tool for CUPS. You can also use several command line print CUPS clients. These include the lpr, lpc, lpq, and lprm commands. With these clients, you can print documents, list a print queue, reorder it, and remove print jobs, effectively canceling them. For network connections, CUPS features an encryption option for its commands, -E, to encrypt print jobs and print information sent on a network. Table 10-3 shows various printer commands.

Note: The command line clients have the same name, and much the same syntax, as the older LPR and LPRng command line clients used in Unix and older Linux systems.

Printer Management

Description

GNOME Print Manager

GNOME print queue management tool (CUPS).

CUPS Configuration Tool

Prints, manages, and configures CUPS.

lpr options file-list

Prints a file, copies the file to the printer’s spool directory, and places it on the print queue to be printed in turn.
-P printer prints the file on the specified printer.

lpq options

Displays the print jobs in the print queue.
-P printer prints the queue for the specified printer.
-l prints a detailed listing.

lpstat options

Displays printer status.

lprm options printjob-id or printer

Removes a print job from the print queue. You identify a particular print job by its number as listed by lpq.
-P printer removes all print jobs for the specified printer.

lpc

Manages your printers. At the lpc> prompt, you can enter commands to check the status of your printers and take other actions.

 Table 10-3: CUPS Print Clients

lpr

The lpr client submits a job, and lpd then takes it in turn and places it on the appropriate print queue; lpr takes as its argument the name of a file. If no printer is specified, then the default printer is used. The -P option enables you to specify a particular printer. In the next example, the user first prints the file preface and then prints the file report to the printer with the name myepson:

$ lpr preface
$ lpr -P myepson report

lpc

You can use lpc to enable or disable printers, reorder their print queues, and re-execute configuration files. To use lpc, enter the command lpc at the shell prompt. You are then given an lpc> prompt at which you can enter lpc commands to manage your printers and reorder their jobs. The status command with the name of the printer displays whether the printer is ready, how many print jobs it has, and so on. The stop and start commands can stop a printer and start it back up. The printers shown depend on the printers configured for a particular print server. A printer configured on CUPS will only show if you have switched to CUPS.

$ lpc
lpc> status myepson
myepson:
printer is on device 'hal' speed -1
queuing is enabled
printing is enabled
1 entry in spool area

lpq and lpstat

You can manage the print queue using the lpq and lprm commands. The lpq command lists the printing jobs currently on the print queue. With the -P option and the printer name, you can list the jobs for a particular printer. If you specify a username, you can list the print jobs for that user. With the -l option, lpq displays detailed information about each job. If you want information on a specific job, simply use that job’s ID number with lpq. To check the status of a printer, use lpstat.

$ lpq
myepson is ready and printing
Rank    Owner  Jobs  File(s)          Total Size
active  chris    1   report           1024

lprm

The lprm command enables you to remove a print job from the queue, erasing the job before it can be printed. The lprm command takes many of the same options as lpq. To remove a specific job, use lprm with the job number. To remove all printing jobs for a particular printer, use the -P option with the printer name. lprm with no options removes the job printing currently. The following command removes the first print job in the queue (use lpq to obtain the job number):

lprm 1

CUPS Command Line Administrative Tools

CUPS provides command-line administrative tools like lpadmin, lpoptions, lpinfo, cupsenable, cupsdisable, accept, and reject. The cupsenable and cupsdisable commands start and stop print queues directly, whereas the accept and reject commands start and stop particular jobs. The lpinfo command provides information about printers, and lpoptions lets you set printing options. The lpadmin command lets you perform administrative tasks like adding printers and changing configurations. CUPS administrative tools are listed in Table 10-4.

lpadmin

You can use the lpadmin command to either set the default printer or configure various options for a printer. You can use the -d option to specify a particular printer as the default destination. Here myepson is made the default printer:

lpadmin -d myepson

The -p option lets you designate a printer for which to set various options. The following example sets printer description information:

lpadmin -p myepson  -D  Epson550

Certain options let you control per-user quotas for print jobs. The job-k-limit option sets the size of a job allowed per user, job-page-limit sets the page limit for a job and job-quota-period limits the number of jobs with a specified time frame. The following command set a page limit of 100 for each user:

lpadmin -p myepson  -o job-page-limit=100

Administration Tool

Description

lpadmin

CUPS printer configuration

lpoptions

Sets printing options

cupsenable

Activates a printer

cupsdisable

Stops a printer

accept

Allows a printer to accept new jobs

reject

Prevents a printer from accepting print jobs

lpinfo

Lists CUPS devices available

 Table 10-4: CUPS Administrative Tools

User access control is determined with the -u option with an allow or deny list. Users allowed access are listed following the allow: entry and those denied access are listed with a deny: entry. Here access is granted to chris but denied to aleina and larisa.

lpadmin -p myepson -u allow:chris  deny:aleina,larisa

Use all or none to permit or deny access to all or no users. You can create exceptions by using all or none in combination with user-specific access. The following example allows access to all users except justin:

lpadmin -p myepson  -u allow:all   deny:justin

lpoptions

The lpoptions command lets you set printing options and defaults that mostly govern how your print jobs will be printed. For example, you can set the color or page format to be used with a particular printer. Default settings for all users are maintained by the root user in the /etc/cups/lpoptions file, and each user can create their own configurations, which are saved in their .lpoptions files. The -l option lists current options for a printer, and the -p option designates a printer (you can also set the default printer to use with the -d option).

lpoptions -p myepson -l

Printer options are set using the -o option along with the option name and value, -o option=value. You can remove a printer option with the -r option. For example, to print on both sides of your sheets, you can set the sides option to two-sided:

lpoptions -p myepson -o sides=two-sided

To remove the option, use -r.

lpoptions -p myepson -r sides

To display a listing of available options, check the standard printing options in the CUPS Software Manual at https://www.cups.org/.

 cupsenable and cupsdisable

The cupsenable command starts a printer, and the cupsdisable command stops it. With the -c option, you can cancel all jobs on the printer's queue, and the -r option broadcasts a message explaining the shutdown.

cupsdisable myepson

 accept and reject

The accept and reject commands let you control access to the printer queues for specific printers. The reject command prevents a printer from accepting jobs, whereas accept allows new print jobs.

reject myepson

 lpinfo

The lpinfo command is a handy tool for letting you know what CUPS devices and drivers that are available on your system. Use the -v option for devices and the -m option for drivers.

lpinfo -m

11. Network File Systems and Network Information Service: NFS and NIS

Linux provides several tools for accessing files on remote systems connected to a network. The Network File System (NFS) enables you to connect to and directly access resources such as files or devices like CD-ROMs that reside on another machine. The latest version, NFSv4, provides greater security, with access allowed by your firewall. It is the default NFS server for Fedora. The Network Information Service (NIS) maintains configuration files for all systems on a network.

Portmapper and RPC Services

Both NFS and NIS are Remote Procedure Call services (RPC). To work, you first have to have the portmapper service enabled and running. The portmapper maps an address to an RPC service, locating the RPC service. It tells hosts where the NFS and NIS services can be found on the system. The name of the portmapper service is rpcbind. Use cockpit or the systemctl command to start it if it not already running.

sudo systemctl start rpcbind

Network File System: NFS

NFS enables you to mount a file system on a remote computer as if it were local to your own system. You can then directly access any of the files on that remote file system. This has the advantage of allowing different systems on a network to access the same files directly, without each having to keep its own copy. Only one copy will be on a remote file system, which each computer can then access. You can find out more about NFS at its website at https://nfs.sourceforge.net.

NFS Daemon

systemd unit file

Description

rpc.nfsd

nfs-server.service

Receives NFS requests from remote systems and translates them into requests for the local system.

rpc.mountd

nfs-mountd.service

Performs requested mount and unmount operations.

rpc.statd

nfs-lock.service
rpc-statd.service

Provides locking services when a remote host reboots.

rpc.idmapd

nfs-idmapd.service

Maps user and group IDs to names.

rpc.gssd

nfs-secure.service
rpc-gssd.service

Client support for the rpcsec_gss protocol for gss-api security in NFSv4.

rpc.svcgssd

nfs-secure-server.service

Server support for the rpcsec_gss protocol for gss-api security in NFSv4.

Table 11-1: NFS daemons and systemd unit files

NFS Daemons

NFS operates over a TCP/IP network. The remote computer that holds the file system makes it available to other computers on the network. It does so by exporting the file system, which entails making entries in an NFS configuration file called /etc/exports, as well as by running several daemons to support access by other systems. These include rpc.mountd, rpc.nfsd, and rpc.gssd. Access to your NFS server can be controlled by the /etc/hosts.allow and /etc/hosts.deny files. The NFS daemons are managed by systemd using several service unit files located in /lib/systemd/system. The NFS daemons and their systemd unit files are listed in Table 11-1.

The nfs-server.service file is shown here.  Runtime configuration information is read from /etc/sysconfig/nfs (EnvironmentFile). 

nfs-server.service

[Unit]
Description=NFS Server and services
DefaultDependencies=no
Requires= network.target proc-fs-nfsd.mount
Requires=nfs-mountd.service
Wants=rpc-statd.service  nfs-idmapd.service
Wants=rpc-statd-notify.service

After=network-online.target local-fs.target
After=proc-fs-nfsd.mount rpcbind.target nfs-mountd.service
After=nfs-idmapd.service nfs-statd.service
Before=rpc-statd-notify.service

# GSS services dependencies and ordering
Wants=auth-rpcgss-module.service
After=rpc-gssd.service gssproxy.service rpd-svcgssd.service

Wants=nfs-config.service
After=nfs-config.service

[Service]
EnvironmentFile=-/etc/sysconfig/nfs-utils

Type=oneshot
RemainAfterExit=yes
ExecStartPre=/usr/sbin/exportfs -r
ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
ExecStart=/bin/sh -C 'If systemctl -q is-active gssproxy; then systemctl restart gssproxy; fi'
ExecStop=/usr/sbin/rpc.nfsd 0
ExecStopPost=/usr/sbin/exportfs -au
ExecStopPost=/usr/sbin/exportfs -f

ExecReload=/usr/sbin/exportfs -r

[Install]
WantedBy=multi-user.target

You can start up and shut down the NFS daemons using the nfs.service file with the systmectl command. Be sure it is enabled.

sudo systemctl enable nfs-server
sudo systemctl start nfs-server

The corresponding systemd unit files for the nfsd, mountd, idmapd, statd, and svcgssd daemons, will run these daemons (nfs- and rpc- prefixes).

The Fedora NFS server and support tools are located in the following packages.

nfs-utils

NFS server and supporting tools

nfs4-acl-tools

Access control list commands for NFS4 supported security

nfswatch

Monitor NFS usage

Make sure that your firewall allows NFS access, make sure that NFS4 is checked. Also be sure to allow SELinux to permit NFS access. Using system-config-selinux select Boolean on the sidebar, and then locate NFS and make sure "Support NFS home directories" is checked.

NFS Configuration: /etc/exports

An entry in the /etc/exports file specifies the file system to be exported and the hosts on the network that can access it. For the file system, enter its mountpoint, the directory to which it was mounted on the host system. This is followed by a list of hosts that can access this file system along with options to control that access. A comma-separated list of export options placed within a set of parentheses may follow each host. For example, you might want to give one host read-only access and another read and write access. If the options are preceded by an * symbol, they are applied to any host. A list of options is provided in Table 11-2. The format of an entry in the /etc/exports file is shown here:

directory-pathname   host-designation(options)

NFS Host Entries

You can have several host entries for the same directory, each with access to that directory:

directory-pathname   host(options) host(options)  host(options)

You have a great deal of flexibility when specifying hosts. For hosts within your domain, you can just use the hostname, whereas, for those outside, you need to use a fully qualified domain name. You can also use just the host’s IP address. Instead of a single host, you can reference all the hosts within a specific domain, allowing access by an entire network. A simple way to do this is to use the * for the host segment, followed by the domain name for the network, such as *.mytrek.com for all the hosts in the mytrek.com network. Instead of domain names, you can use IP network addresses with a CNDR format where you specify the netmask to indicate a range of IP addresses.

You can also use an NIS netgroup name to reference a collection of hosts. The NIS netgroup name is preceded by an @ sign.

directory     host(options)
directory     *(options)
directory     *.domain(options)
directory     192.168.1.0/255.255.255.0(options)
directory     @netgroup(options)

General Option

Description

secure

Requires that requests originate on secure ports, those less than 1024. This is on by default.

insecure

Turns off the secure option.

ro

Allows only read-only access. This is the default.

rw

Allows read/write access.

sync

Performs all writes when requested. This is the default.

async

Performs all writes when the server is ready.

no_wdelay

Performs writes immediately, not checking to see if they are related.

wdelay

Checks to see if writes are related, and if so, waits to perform them together. Can degrade performance. This is the default.

hide

Automatically hides an exported directory that is the subdirectory of another exported directory.

subtree_check

Checks parent directories in a file system to validate an exported subdirectory. This is the default.

no_subtree_check

Does not check parent directories in a file system to validate an exported subdirectory.

insecure_locks

Does not require authentication of locking requests. Used for older NFS versions.

User ID Mapping

Description

all_squash

Maps all UIDs and GIDs to the anonymous user.

no_all_squash

The opposite option to all_squash. This is the default setting.

root_squash

Maps requests from remote root user to the anonymous UID/GID. This is the default.

no_root_squash

Turns off root squashing. Allows the root user to access as the remote root.

anonuid

Sets explicitly the UID and GID of the anonymous account used for all_squash and root_squash options.

 Table 11-2: The /etc/exports Options

NFS Options

Options in /etc/exports operate as permissions to control access to exported directories. Read-only access is set with the ro option, and read/write with the rw option. The sync and async options specify whether a write operation is performed immediately (sync) or when the server is ready to handle it (async). By default, write requests are checked to see if they are related, and if so, they are written together (wdelay). This can degrade performance. You can override this default with no_wdelay and have writes executed as they are requested. If two directories are exported, where one is the subdirectory of another, the subdirectory is not accessible unless it is explicitly mounted (hide). In other words, mounting the parent directory does not make the subdirectory accessible. The subdirectory remains hidden until also mounted. You can overcome this restriction with the no_hide option (though this can cause problems with some file systems). If an exported directory is actually a subdirectory in a larger file system, its parent directories are checked to make sure that the subdirectory is the valid directory (subtree_check). This option works well with read-only file systems but can cause problems for write-enabled file systems, where filenames and directories can be changed. You can cancel this check with the no_subtree_check option.

NFS User-Level Access

Along with general options, there are also options that apply to user-level access. As a security measure, the client’s root user is treated as an anonymous user by the NFS server. This is known as squashing the user. In the case of the client root user, squashing prevents the client from attempting to appear as the NFS server’s root user. Should you want a particular client’s root user to have root-level control over the NFS server, you can specify the no_root_squash option. To prevent any client user from attempting to appear as a user on the NFS server, you can classify them as anonymous users (the all_squash option). Such anonymous users only have access to directories and files that are part of the anonymous group.

Normally, if a user on a client system has a user account on the NFS server, that user can mount and access his or her files on the NFS server. However, NFS requires the User ID for the user be the same on both systems. If this is not the case, he or she is considered to be two different users. To overcome this problem, you can use an NIS service, maintaining User ID information in just one place, the NIS password file.

NFS /etc/exports Example

Examples of entries in an /etc/exports file are shown here. Read-only access is given to all hosts to the file system mounted on the /pub directory, a common name used for public access. Users, however, are treated as anonymous users (all_squash). Read and write access is given to the lizard.mytrek.com computer for the file system mounted on the /home/mypics directory. The next entry allows access by rabbit.mytrek.com to the NFS server’s CD-ROM, using only read access. The last entry allows anyone secure access to /home/richlp.

/etc/exports

/pub                *(ro,insecure,all_squash,sync)
/home/mypics       lizard.mytrek.com(rw,sync)
/media/cdrom        rabbit.mytrek.com(ro,sync)
/home/richlp        *(secure,sync)

Applying Changes

Each time your system starts up the NFS server (usually when the system starts up), the /etc/exports file will be read and those directories specified will be exported. When a directory is exported, an entry for it is made in the /var/lib/nfs/xtab file. It is this file that NFS reads and uses to perform the actual exports. Entries are read from /etc/exports and corresponding entries made in /var/lib/nfs/xtab. The xtab file maintains the list of actual exports.

If you want to export added entries in the /etc/exports file immediately, without rebooting, you can use the exportfs command with the -a option. It is helpful to add the -v option to display the actions that NFS is taking. Use the same options to effect any changes you make to the /etc/exports file.

exportfs -a -v

If you later make changes to the /etc/exports file, you can use the -r option to re-export its entries. The -r option will re-sync the /var/lib/nfs/xtab file with the /etc/exports entries, removing any other exports or any with different options.

exportfs -r -v

To both export added entries and re-export changed ones, you can combine the -r and -a options.

exportfs -r -a -v

Manually Exporting File Systems

You can also use the exportfs command to manually export file systems instead of using entries for them in the /etc/exports file. Export entries will be added to the /var/lib/nfs/xtab file directly. With the -o option, you can list various permissions and then follow them with the host and file system to export. The host and file system are separated by a colon. For example, to manually export the /home/myprojects directory to golf.mytrek.com with the permissions ro and insecure, you use the following:

exportfs -o rw,insecure golf.mytrek.com:/home/myprojects

You can also use exportfs to un-export a directory that has already been exported, either manually or by the /etc/exports file. Just use the -u option with the host and the directory exported. The entry for the export will be removed from the /var/lib/nfs/xtab file. The following example will un-export the /home/foodstuff directory that was exported to lizard.mytrek.com:

exportfs -u lizard.mytrek.com:/home/foodstuff

NFSv4

  NFS version 4 is the new version of the NFS protocol with enhanced features like greater security, reliability, and speed. It is the default NFS server for Fedora. The NFS client (nfs-utils package) supports both NFSv3 and NFSv4. When you mount an NFSv4 file system, you use still use the nfs file type. See the nfs man page for more details.

Fedora also configures the term nfs as an alias for nfs4, so any use of nfs4 is interpreted as nfs. Any use of nfs4 in older systems is interpreted as nfs. The following alias entry is located in the /etc/modprobe.d/dist.conf file.

alias nfs4 nfs

In the /etc/exports file, you can use the fsid=0 option to specify the root export location.

 /home/richlp          *(fsid=0,ro,sync)

The preceding entry lets you mount the file system to the /home/richlp directory without having to specify it in the mount operation.

mount -t nfs  rabbit.mytrek.com:/  /home/dylan/projects

NFSv4 also supports the RPCSEC_GSS (Remote Procedure Call Security, Generic Security Services) security mechanism which provides for private/public keys, encryption, and authentication.

Tip: To see what file systems are exported currently by an NFS server, you can use the showmount command with the -e option, showmount -e nfserver. To see what client hosts mount file systems on the NFS server, you use showmount with no options.

NFS File and Directory Security with NFS4 Access Lists

With NFS4 you can set up access control lists (ACL) for particular directories and files. You use the NFS4 ACL tools to manage these lists (nfs4-acl-tools package). The NFS4 file system ACL tools include nfs4_getfacl, nfs4_setfacl, and nfs4_editfacl. Check the Man page for each for detailed options and examples. nfs4_getfacl will list the access controls for a specified file or directory. nfs4_setfacl will create access controls for a directory or file, and nfs4_editfacl will let you change them. nfs4_editfacl simply invokes nfs_setfacl with the -e option. When editing access controls, you are placed in an editor where you can make your changes. For setting access controls you can read from a file, the standard input, or list the control entries on the command line.

The file and directory access controls are more refined that the standard permissions. The ACL entries follow the syntax described in detail on the nfs4_acl Man page. An ACL entry begins with an entry type such as an accept or deny entry (A or D); followed by an ACL flag, which can specify group or inheritance capability and then the principal to which the ACL is applied; and finally, the list of access options, such as r for read or w for write. The principal is usually a user URL that is to be permitted or denied access. You can also specify groups, but you need to set the g group flag. The special URLs OWNER@, GROUP@, and EVERYONE@ correspond to the owner, group, and other access used on standard permissions. The following example provides full access to the owner but gives only read and execute access to the user george@rabbit.com. Group write and execute access is denied.

A::OWNER@:rwadtTnNcCy
A::george@rabbit.com:rxtncy
D:g:GROUP@:waxtc

In addition to read, write, and execute permissions (r,w,x), ACL lists also provide attribute reads (t,n) and attribute writes (T,N), as well as ACL read (c) and write (C) access. NFS read and write synchronization is enabled with the y option. The ability to delete files and directories is provided by the d option and for subdirectories with the D option. The a option lets you append data and create subdirectories. Keep in mind that rtncy are all read options, whereas wadDTNC are write options, while x remains the execute option. You will need y for any synchronized access. The C option, in particular, is very powerful as it allows the user to change the access controls (lowercase c allows only reading of the access controls).

Controlling Accessing to NFS Servers

You can use several methods to control access to your NFS server, such as using hosts.allow and hosts.deny to permit or deny access, as well as using your firewall to intercept access.

 /etc/hosts.allow and /etc/hosts.deny

The /etc/hosts.allow and /etc/hosts.deny files are used to restrict access to services provided by your server to hosts on your network or on the Internet (if accessible). For example, you can use the hosts.allow file to permit access by certain hosts to your FTP server. Entries in the hosts.deny file explicitly deny access to certain hosts. For NFS, you can provide the same kind of security by controlling access to specific NFS daemons. The entries in the hosts.allow file are the same you specified in the shares-admin tool's Add Allow hosts window (Share Folder).

Portmapper Service

The first line of defense is to control access to the portmapper service. The portmapper tells hosts where the NFS services can be found on the system. Restricting access does not allow a remote host to even locate NFS. For a strong level of security, you should deny access to all hosts except those that are explicitly allowed. In the hosts.deny file, you place the following entry, denying access to all hosts by default. ALL is a special keyword denoting all hosts.

portmap:ALL

In the hosts.allow file, you then enter the hosts on your network, or any others that you want to permit access to your NFS server. Again, you specify the portmapper service and then list the IP addresses of the hosts you are permitting access. You can list specific IP addresses or a network range using a netmask. The following example allows access only by hosts in the local network, 192.168.0.0, and to the host 10.0.0.43. You can separate addresses with commas:

portmap: 192.168.0.0/255.255.255.0, 10.0.0.43

The portmapper is also used by other services such as NIS. If you close all access to the portmapper in hosts.deny, you will also need to allow access to NIS services in hosts.allow, if you are running them. These include ypbind and ypserver. In addition, you may have to add entries for remote commands like ruptime and rusers, if you are supporting them.

It is also advisable to add the same level of control for specific NFS services. In the hosts.deny file, you add entries for each service, as shown here:

mountd:ALL
rquotad:ALL
statd:ALL
lockd:ALL

Then, in the hosts.allow file, you can add entries for each service:

mountd:  192.168.0.0/255.255.255.0, 10.0.0.43
rquotad: 192.168.0.0/255.255.255.0, 10.0.0.43
statd:   192.168.0.0/255.255.255.0, 10.0.0.43
lockd:   192.168.0.0/255.255.255.0, 10.0.0.43

Netfilter Rules

You can further control access using Netfilter to check transmissions from certain hosts on the ports used by NFS services. portmapper uses port 111, and nfsd uses 2049. Netfilter is helpful if you have a private network that has an Internet connection and you want to protect it from the Internet. Usually, a specific network device, such as an Ethernet card, is dedicated to the Internet connection. The following examples assume that device eth1 is connected to the Internet. Any packets attempting access on port 111 or 2049 are refused.

iptables -A INPUT -i eth1 -p 111 -j DENY
iptables -A INPUT -i eth1 -p 2049 -j DENY

To enable NFS for your local network, you will have to allow packet fragments. Assuming that eth0 is the device used for the local network, you could use the following example:

iptables -A INPUT -i eth0 -f -j ACCEPT

 Mounting NFS File Systems: NFS Clients

Once NFS makes directories available to different hosts, those hosts can then mount those directories on their own systems and access them. The host needs to be able to operate as an NFS client. Current Linux kernels all have NFS client capability built in. This means that any NFS client can mount a remote NFS directory that it has access to by performing a simple mount operation.

Mounting NFS Automatically: /etc/fstab

You can mount an NFS directory either by an entry in the /etc/fstab file or by an explicit mount command. You have your NFS file systems mounted automatically by placing entries for them in the /etc/fstab file. An NFS entry in the /etc/fstab file has a mount type of NFS. An NFS file system name consists of the hostname of the computer it is located on, followed by the pathname of the directory where it is mounted. The two are separated by a colon. For example, rabbit.trek.com:/home/project specifies a file system mounted at /home/project on the rabbit.trek.com computer. The format for an NFS entry in the /etc/fstab file follows. The file type for NFS versions 1 through 3 is nfs, whereas for NFS version 4 it is nfs4.

host:remote-directory    local-directory      nfs   options   0   0

You can also include several NFS-specific mount options with your NFS entry. You can specify the size of datagrams sent back and forth and the amount of time your computer waits for a response from the host system. You can also specify whether a file system is to be hard-mounted or soft-mounted. For a hard-mounted file system, your computer continually tries to make contact if for some reason the remote system fails to respond. A soft-mounted file system, after a specified interval, gives up trying to make contact and issues an error message. A hard mount is the default. A system making a hard-mount attempt that continues to fail will stop responding to user input as it tries continually to achieve the mount. For this reason, soft mounts may be preferable, as they will simply stop attempting a mount that continually fails. Table 11-3 and the Man pages for mount contain a listing of these NFS client options. They differ from the NFS server options indicated previously.

An example of an NFS entry follows. The remote system is rabbit.mytrek.com, and the file system is mounted on /home/projects. This file system is to be mounted on the local system as the /home/dylan/projects directory. The /home/dylan/projects directory must already be created on the local system. The type of system is NFS, and the timeo option specifies the local system waits for up to 20 tenths of a second (two seconds) for a response. The mount is a soft mount and can be interrupted by NFS.

rabbit.mytrek.com:/home/projects /home/dylan/projects  nfs  soft,intr,timeo=20

Option

Description

rsize=n

The number of bytes NFS uses when reading files from an NFS server. The default is 1,024 bytes. A size of 8,192 can greatly improve performance.

wsize=n

The number of bytes NFS uses when writing files to an NFS server. The default is 1,024 bytes. A size of 8,192 can greatly improve performance.

timeo=n

The value in tenths of a second before sending the first retransmission after a timeout. The default value is seven-tenths of a second.

retry=n

The number of minutes to retry an NFS mount operation before giving up. The default is 10,000 minutes (one week).

retrans=n

The number of retransmissions or minor timeouts for an NFS mount operation before a major timeout (default is 3). At that time, the connection is canceled or a “server not responding” message is displayed.

soft

Mount system using soft mount.

hard

Mount system using hard mount. This is the default.

intr

Allows NFS to interrupt the file operation and return to the calling program. The default is not to allow file operations to be interrupted.

bg

If the first mount attempt times out, continues trying the mount in the background. The default is to fail without backgrounding.

tcp

Mounts the NFS file system using the TCP protocol, instead of the default UDP protocol.

 Table 11-3: NFS Mount Options

 Mounting NFS Manually: mount

You can also use the mount command with the -t nfs option to mount an NFS file system explicitly. For an NFSv4 file system you use -t nfs4. To mount the previous entry explicitly, use the following command:

mount -t nfs -o soft,intr,timeo=20 rabbit.mytrek.com:/home/projects \ /home/dylan/projects

You can, of course, unmount an NFS directory with the umount command. You can specify either the local mountpoint or the remote host and directory, as shown here:

umount /home/dylan/projects
umount  rabbit.mytrek.com:/home/projects

 Mounting NFS on Demand: autofs

You can also mount NFS file systems using the automount service, autofs. This requires added configuration on the client’s part. The autofs service will mount a file system only when you try to access it. A directory change operation (cd) to a specified directory will trigger the mount operation, mounting the remote file system at that time.

The autofs service is configured using a master file to list map files, which in turn lists the file systems to be mounted. The /etc/auto.master file is the autofs master file. The master file will list the root pathnames where file systems can be mounted along with a map file for each of those pathnames. The map file will then list a key (subdirectory), mount options, and the file systems that can be mounted in that root pathname directory. On some distributions, the /auto directory is already implemented as the root pathname for file systems automatically mounted. You can add your own file systems in the /etc/auto.master file along with your own map files, if you wish. You will find that the /etc/auto.master file contains the following entry for the /auto directory, listing auto.misc as its map file:

/auto    auto.misc   --timeout 60

Following the map file, you can add options, as shown in the preceding example. The timeout option specifies the number of seconds of inactivity to wait before trying to automatically unmount.

In the map file, you list the key, the mount options, and the file system to be mounted. The key will be the subdirectory on the local system where the file system is mounted. For example, to mount the /home/projects directory on the rabbit.mytrek.com host to the /auto/projects directory, you use the following entry:

projects  soft,intr,timeo=20   rabbit.mytrek.com:/home/projects

You can also create a new entry in the master file for an NFS file system, as shown here:

/myprojects    auto.myprojects   --timeout 60

You then create an /etc/auto.myprojects file and place entries in it for NFS files system mounts, like the following:

dylan    soft,intr,rw   rabbit.mytrek.com:/home/projects
newgame  soft,intr,ro   lizard.mytrek.com:/home/supergame

Network Information Service: NIS

On networks supporting NFS, many resources and devices are shared by the same systems. Normally, each system needs its own configuration files for each device or resource. Changes entail updating each system individually. However, NFS provides a special service called the Network Information System (NIS) that maintains such configuration files for the entire network. For changes, you need only to update the NIS files. NIS works for information required for most administrative tasks, such as those relating to users, network access, or devices. For example, you can maintain user and password information with an NIS service, having only to update those NIS password files.

Note: NIS+ is a more advanced form of NIS that provides support for encryption and authentication. However, it is more difficult to administer.

NIS was developed by Sun Microsystems and was originally known as Sun’s Yellow Pages (YP). NIS files are kept on an NIS server (NIS servers are still sometimes referred to as YP servers). Individual systems on a network use NIS clients to make requests from the NIS server. The NIS server maintains its information on special database files called maps. Linux versions exist for both NIS clients and servers. Linux NIS clients easily connect to any network using NIS.

Note: Instead of NIS, many networks now use LDAP to manage user information and authentication.

The NIS client is installed as part of the initial installation with the ypbind and yp-tools packages. The NIS server can be installed from the ypserv package. NIS client programs are ypbind (the NIS daemon, ypbind package), ypwhich, ypcat, yppoll, ypmatch, yppasswd, and ypset (yp-tools package). Each has its own Man page with details of its use. The NIS server programs are ypserv (the NIS server package, ypserv), ypinit, yppasswdd, yppush, ypxfr, and netgroup, each also with its own Man page.

You can start and stop the ypbind client daemon and the ypserv NIS server with the systemctl command. Be sure it is enabled. Alternatively, you can use cockpit to start and stop the NIS client and server daemons.

sudo systemctl enable ypbind
sudo systemctl enable ypserv
sudo systemctl start ypbind
sudo systemctl start ypserv

The NIS server is managed by systemd using the ypbind.service and ypserv.service unit file. Runtime configuration is read from /etc/sysconfig/ypbind (EnvironmentFile). SELinux (setsebool) is configured to allow access (ExecStartPre).

ypbind.service

[Unit]
Description=NIS/YP (Network Information Service) Clients to NIS Domain Binder
Requires=rpcbind.service
Wants=nss-user-lookup.target network-online.target
After=syslog.target network.target rpcbind.service ypserv.service
Before=systemd-user-sessions.service
Before=nss-user-lookup.target

[Service]
Type=notify
NotifyAccess=all
EnvironmentFile=-/etc/sysconfig/network
EnvironmentFile=-/etc/sysconfig/ypbind
ExecStartPre=/usr/libexec/ypbind-pre-setdomain
ExecStartPre=-/usr/sbin/setsebool allow_ypbind=1
ExecStart=/usr/sbin/ypbind -n $OTHER_YPBIND_OPTS
ExecStartPost=/usr/libexec/ypbind-post-waitbind
PrivateTmp=true

[Install]
WantedBy=multi-user.target

The ypserv.service file simply starts the NIS server (/usr/sbin/ypserv) .

ypserv.service

[Unit]
Description=NIS/YP (Network Information Service) Server
Requires=rpcbind.service
After=syslog.target network.target rpcbind.service

[Service]
Type=notify
NotifyAccess=all
EnvironmentFile=-/etc/sysconfig/network
ExecStart=/usr/sbin/ypserv -f $YPSERV_ARGS
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Note: You can use system-config-authentication to specify the remote NIS server on your network.

NIS Servers

You have significant flexibility when setting up NIS servers. If you have a small network, you may need only one NIS domain, for which you would have one NIS server. For larger networks, you can divide your network into several NIS domains, each with its own server. Even if you only have one domain, you may want several NIS slave servers. For an NIS domain, you can have a master NIS server and several NIS slave servers. The slave servers can act as backups, in case the master server goes down. A slave server only contains copies of the configuration files set up on the NIS master server.

Configuring an NIS server involves several steps, listed here:

Define the NIS domain name that the NIS server will work for.

Start the ypserv daemon.

In the /var/yp/Makefile file, set any NIS server options and specify the configuration files to manage.

Use /usr/lib/ypinit to create the NIS versions of the configuration files.

Defining NIS Domain

You first have to define an NIS domain name. You can have the NIS domain defined whenever you start up your system, by defining the NIS_DOMAIN variable in the /etc/sysconfig/network file. To this variable, you assign the name you want to give your NIS domain. The following example defines the NIS domain called myturtles.nis:

NIS_DOMAIN=myturtles.nis

When first setting up the server, you may want to define your NIS domain name without having to restart your system. You can do so with the domainname command, as shown here:

domainname myturtles.nis

NIS server options are kept in the /etc/ypserv.conf file. Check the man page for that file for details. You can start the NIS server with the ypserv startup script:

service ypserv start

Setting NIS Server Options

Next edit the /var/yp/Makefile file to select the configuration files that the NIS server will maintain, along with setting any NIS server options. Standard options as well as most commonly used configuration files are usually already set up.

NIS server options are listed first. The NOPUSH option will be set to true, indicating that there are no slave NIS servers. If you are setting up any slave NIS servers for this domain, you will have to set this option to false:

NOPUSH = true

The minimum user and group IDs are set to 500. These are set using the MINUID and MINGID variables:

MINUID=500
MINGID=500

Most distributions use a shadow password and shadow group files to encrypt passwords and groups; the MERGE_PASSWD and MERGE_GROUP settings will be set to true. NIS will merge shadow password information into its password file:

MERGE_PASSWD=true
MERGE_GROUP=true

The directories where NIS will find password and other configuration files are then defined using the YPSRCDIR and YPPWDIR variables. Normally, the /etc directory holds your configuration files:

YPSRCDIR = /etc
YPPWDDIR = /etc

Then the configuration files that NIS can manage are listed. Here, you will find entries like PASSWD for password, GROUP for your groups, and PRINTCAP for your printers. A sample of the entries are shown here:

GROUP       = $(YPPWDDIR)/group
PASSWD      = $(YPPWDDIR)/passwd
SHADOW      = $(YPPWDDIR)/shadow
GSHADOW     = $(YPPWDDIR)/gshadow
ALIASES     = /etc/aliases
ETHERS      = $(YPSRCDIR)/ethers     # ethernet addresses (for rarpd)
BOOTPARAMS  = $(YPSRCDIR)/bootparams # for booting Sun boxes (bootparamd)
HOSTS       = $(YPSRCDIR)/hosts
NETWORKS    = $(YPSRCDIR)/networks
PRINTCAP    = $(YPSRCDIR)/printcap
PROTOCOLS   = $(YPSRCDIR)/protocols

Specifying Shared Files

The actual files that are shared on the network are listed in the all: entry, which follows the list of configuration files. Only some of the files defined are listed as shared, those listed in the first line after all:. The remaining lines are automatically commented out (with a preceding # sign). You can add files by removing the # sign or moving their entries to the first line.

all:  passwd group hosts rpc services netid protocols mail \
      # netgrp shadow publickey networks ethers bootparams printcap \
      # amd.home auto.master auto.home auto.local passwd.adjunct \
      # timezone locale netmasks

Be sure not to touch the remainder of the Makefile.

Creating the NIS Database

You then enter the ypinit command with the -m option to create the NIS database consisting of the NIS configuration files. Your NIS server will be detected, and then you will be asked to enter the names of any slave NIS servers used on this NIS domain. If there are any, enter them. When you are finished, press ctrl-d. The NIS database files are then created.

ypinit -m

For an NIS slave server, you would use

ypinit -s masterhost

Should you receive the following error, it most likely means that your NIS server was not running. Be sure to start ypserv before you run ypinit.

failed to send 'clear' to local ypserv: RPC: Program not registeredUpdating

If you later need to update your NIS server files, you would change to the /var/yp directory and issue the make command.

cd /var/yp
make

Controlling Access

The /var/yp/securenets file enables access by hosts to your NIS server. Hosts can be referenced by network or individually. Entries consist of a subnet mask and an IP address. For example, you could give access to all the hosts in a local network with the following entry:

255.255.255.0  192.168.1.0

For individual hosts, you can use the mask 255.255.255.255 or just the term “host,” as shown here:

host   192.168.1.4

Controlling how different hosts access NIS shared data is determined in /etc/ypserv.conf.

Netgroups

You can use NIS to set up netgroups, which allow you to create network-level groups of users. Whereas normal groups are created locally on separate hosts, an NIS netgroup can be used for network-wide services. For example, you can use NIS netgroups to control access to NFS file systems. Netgroups are defined in the /etc/netgroup file. Entries consist of a netgroup name followed by member identifiers consisting of three segments: the host, the user, and the NIS domain:

group    (host, user, NIS-domain) (host, user, NIS-domain) ...

For example, in the NIS domain myturtles.nis, to define a group called myprojects that consist of the user chris on the host rabbit, and the user george on the host lizard.mytrek.com, you would use the following:

myprojects (rabbit, chris, myturtles.nis) \
                          (lizard.mytrek.com, george, myturtles.nis)

A blank segment will match on any value. The following entry includes all users on the host rabbit:

newgame (rabbit,,myturtles.ni)

If your use of a group doesn't need either a user or a host segment, you can eliminate one or the other using a hyphen (-). The following example generates a netgroup consisting just of hostnames, with no usernames:

myservers (rabbit,-,) (turtle.mytrek.com,-,)

You can then reference different netgroups in various configuration files by prefixing the netgroup name with an @ sign, as shown here:

@newgame

NIS Clients

For a host to use NIS on your network, you first need to specify your NIS domain name on that host. In addition, your NIS clients need to know the name of your NIS server. If you installed Linux on a network already running NIS, you may have already entered this information during the installation process. NIS client applications are installed with the yp-tools package.

Specifying the NIS Domain and Server

You can specify your NIS domain name and server with the authconfg-gtk tool, which you can access from the System Settings window. In that window, select Authentication. This opens the Authentication Configuration window. On the User Information panel, click the Configure NIS button to open a dialog where you can enter the name of the NIS domain as well as the NIS server. Be sure to also enable NIS on the User Information panel. The NIS domain will be saved in the /etc/sysconfig/network file, and the NIS server, in the /etc/yp.conf file.

Accessing the Server

Each NIS client host on your network then has to run the ypbind NIS client to access the server. In the client’s /etc/yp.conf file, you need to specify the NIS server it will use. The following entry would reference the NIS server at 192.168.1.1:

ypserver 192.168.1.1

Alternatively, you can specify the NIS domain name and the server it uses:

domain mydomain.nis  server servername

The authconfg-gtk tool will make the following entry in /etc/yp.conf for the myturtle.nis NIS domain using the turtle.mytrek.com server:

domain myturtles.nis server turtle.mytrek.com

To start the NIS client, you run the ypbind script:

service ypbind start

Then, to check that all is working, you can use ypcat to try to list the NIS password file:

ypcat passwd.

You can use ypcat to list any of the NIS configuration files. The ypwhich command will display the name of the NIS server your client is using. ypmatch can be used to find a particular entry in a configuration file.

ypmatch cecelia passwd.

Users can change their passwords in the NIS passwd file by using the yppasswd command. It works the same as the passwd command. You will also have to have the yppasswdd daemon running.

Specifying Configuration Files with nsswitch.conf

To ensure that the client accesses the NIS server for a particular configuration file, you should specify nisplus in file’s entry in the /etc/nsswitch.conf file. The nisplus option refers to the NIS version 3. The nis option refers to the older NIS version 2. The /etc/nsswitch.conf file specifies where a host should look for certain kinds of information. For example, the following entry says to check the local configuration files (files) first and then the NIS server (nisplus) for password data:

passwd:   files nisplus

12. Samba

With Samba, you can connect your Windows clients on a Microsoft Windows network to services such as shared files, systems, and printers controlled by the Linux Samba server and, at the same time, allow Linux systems to access shared files and printers on Windows systems. Samba is a collection of Linux tools that allow you to communicate with Windows systems over a Windows network. In effect, Samba allows a Linux system or network to act as if it were a Windows server, using the same protocols as used on a Windows network.

Whereas most Unix and Linux systems use the TCP/IP protocol for networking, Microsoft networking with Windows uses a different protocol, called the Server Message Block (SMB) protocol that implements a local area network (LAN) of computers running Windows. SMB makes use of a network interface called Network Basic Input Output System (NetBIOS) that allows Windows systems to share resources, such as printers and disk space. One Windows systems on such a network can access part of another Windows system's disk drive as if it were its own. SMB was originally designed for small LANs. To connect it to larger networks, including those with Unix systems, Microsoft developed the Common Internet File System (CIFS). CIFS still uses SMB and NetBIOS for Windows networking.

Wanting to connect his Linux system to a Windows PC, Andrew Tridgell wrote an SMB client and server that he called Samba. Samba allows Unix and Linux systems to connect to such a Windows network; as if they were Windows systems. Unix systems can share resources on Windows systems as if they were just another Windows system. Windows systems can also access resources on Unix systems as if they were Windows systems. Samba, in effect, has become a professional-level, open source, and free version of CIFS. Samba effectively enables you to use a Linux or Unix server as a network server for a group of Windows machines operating on a Windows network. You can also use it to share files on your Linux system with other Windows systems, or to access files on a Windows systems from your Linux system, as well as between Windows systems. You can obtain extensive documentation and current releases from the Samba Web and FTP sites at https://www.samba.org. Samba HOW-TO documentation is also available at https://www.tldp.org.

On Fedora, Samba software is incorporated into several packages (see Table 12-1). By selecting the samba server package, needed supporting packages like smbclient and samba-common are automatically selected. Fedora uses Samba 4, the current stable release, which features support for the SMB2 protocol and the Active Directory service.

For  detailed documentation and configuration of Samba on Fedora see the Fedora System Administration Guide | Servers | File and Print Servers | Samba.

https://docs.fedoraproject.org/f28/system-administrators-guide/servers/File_and_Print_Servers.html

Samba Applications

The Samba software package consists of two server daemons and several utility programs (see Table 12-2). One daemon, smbd, provides file and printer services to SMB clients and other systems, such as Windows, that support SMB. The nmbd is a daemon that provides NetBIOS name resolution and service browser support.

Package name

Description

samba

The Samba server

samba-common

Samba Fedora configuration files and support tools

samba-doc

Documentation for Samba, including examples

smbclient

Samba clients for accessing Windows shares.

smbfs

Mount and unmount tools for Samba shares

kdenetwork-filesharing

Implements Samba file sharing by KDE

shares-admin

GNOME Samba file sharing support, installed with GNOME Desktop.

 Table 12-1: Samba packages on Fedora

Application

Description

smb

Samba server daemon that provides file and printer services to SMB clients

nmb

Samba daemon that provides NetBIOS name resolution and service browser support

winbind

Uses authentication services provided by Windows domain

smbclient

Provides FTP-like access by Linux clients to Samba services

mount.cifs

Mounts Samba share directories on Linux clients (used by the mount command with the -t cifs option)

smbpasswd

Changes SMB-encrypted passwords on Samba servers

smbstatus

Displays the current status of the SMB network connections

smbrun

Interface program between smbd and external programs

testparm

Tests the Samba configuration file, smb.conf

smbtar

Backs up SMB/CIFS-shared resources directly to a Unix tape drive

nmblookup

Maps the NetBIOS name of a Windows PC to its IP address

smb.service

The systemd service script for the Samba server

pdbedit

Edit the Samba users database file. This is a Secure Accounts Manager (SAM) database.

smbcontrol

Send the Samba servers administrative messages, like shutdown or close-share.

tdbbackup

Backup the Samba .tdb database files.

 Table 12-2: Samba Applications

The smbclient tool provides FTP-like access by Linux clients to Samba services. The mount.cifs and umount.cifs tools enable Linux clients to mount and unmount Samba shared directories (used by the mount command with the -t samba option). The smbstatus utility displays the current status of the SMB server and who is using it. You use testparm to test your Samba configuration. smbtar is a shell script that backs up SMB/CIFS-shared resources directly to a Unix archive. You can use nmblookup to map the NetBIOS name of a Windows system to its IP address. Configuration files are kept in the /etc/samba directory. Samba configuration file us /etc/samba/smb.conf.

Samba provides four main services: file and printer services, authentication and authorization, name resolution, and service announcement. The SMB daemon, smbd, provides the file and printer services, as well as authentication and authorization for those services. This means users on the network can share files and printers. You can control access to these services by requiring users to provide a password. When users try to access a shared directory, they are prompted for a password. Control can be implemented in share mode or user mode. The share mode sets up one password for the shared resource and then enables any user who has that password to access it. The user mode provides a different password for each user. Samba maintains its own password file for this purpose.

Name resolution and service announcements are handled by the nmbd server. Name resolution resolves NetBIOS names with IP addresses. Service announcements, also known as browsing, are the way a list of services available on the network is made known to the connected Windows PCs (and Linux PCs connected through Samba).

Samba also includes the winbindd daemon, which allows Samba servers to use authentication services provided by a Windows domain. Instead of a Samba server maintaining its own set of users to allow access, it can make use of a Windows domain authentication service to authenticate users.

Setting Up Samba

To allow Windows to access a Linux system, as well as Linux to access a Windows system, you use the Samba server. First be sure that Samba is installed along with the Services tool. You can install the Samba server with the dnf command and the samba package.

sudo dnf install samba

Be sure that the firewall on your Windows system is not blocking Samba (see Figure 12-1). Run firewall-config (Sundry | Firewall) and choose the Services tab. Make sure that the Samba service and Samba client entries are checked, allowing Samba to operate on your system, along with Multicast-DNS. Click Apply to make the changes.

Figure 12-1: Allowing Samba on Firewall

The Samba server consists of two daemons: smb and nmb. You may have to first enable and then start these daemons using the systemctl command with administrative access (sudo). Open a terminal window (System Tools | Terminal), enter a sudo systemctl command for the smb and nmb servers with the enable command to enable the server, and then use the systemctl command with the start command to start it. Once enabled, the server should start automatically whenever your system starts up. Samba is managed by systemd (see Chapter 3).

sudo systemctl nmb enable
sudo systemctl smb enable
sudo systemctl nmb start
sudo systemctl smb start

Also, make sure that Samba access is permitted by SELinux (system-config-selinux). Open the SELinux Management tool, and on the Boolean tab, enable Samba access (see Figure 12-2).  There are several Samba entries.  To share folders, Windows folders, and NFS folders you would check the following:

Allow samba to share any file/directory read/write
Allow samba to export ntfs/fusefs volumes
Allow samba to export NFS volumes

Should you receive a security alert, you can change the Samba SELinux file context manually using the chcon and semanage commands. The commands to enter will be listed in the Fix Command section of the security alert's "Show full error output" scroll window. The Samba share directory's SELinux file context is set to samba_share_t. The semanage command preserves the change through relabelings. In the following example, the SELinux file context for the /mymedia share is set.

chcon -R -t samba_share_t '/mymedia'
semanage fcontext -a  -t samba_share_t '/mymedia'

Samba has two methods of authentication, shares and users. User authentication requires that there be corresponding accounts in the Windows and Linux systems. They can have the same name, though a Windows user can be mapped to a Linux account. A share can be made open to any user and function as an extension of the user’s storage space. The user method is recommended.

Figure 12-2: Allowing Samba on SELinux: system-config-selinux

To set up simple file sharing on a Linux system, you first need to configure your Samba server. You can do this by directly editing the /etc/samba/samba.conf file You first need to specify the name of your Windows network.

Samba is managed by systemd using the smb.service and nmb.service unit files in /etc/systemd/system. The smb.service file is shown here. Samba is started after the system log, networking, nmbd, and the Winbind service (After). It is started for the multi-user.target (runlevels 2, 3, 4, and 5) (WantedBy).  Runtime configuration is read from the /etc/sysconfig/samba file (EnvironmentFile).

smb.service

[Unit]
Description=Samba SMB Daemon
Documentation=man:smbd(8) man:samba(7) man:smb.conf(5)
After=network.target nmbd.service winbind.service

[Service]
Type=notify
NotifyAccess=all
PIDFile=/run/smbd.pid
LimitNOFILE=16384
EnvironmentFile=-/etc/sysconfig/samba
ExecStart=/usr/sbin/smbd --foreground --no-process-group $SMBDOPTIONS
ExecReload=/bin/kill -HUP $MAINPID
LimitCORE=infinity
Environment=KRB5CCNAME=/run/samba/krb5cc_samba

[Install]
WantedBy=multi-user.target

The NMB daemon is started after system logging and networking (After). It also reads runtime configuration from /etc/sysconfig/samba (EnvironmentFile). It starts the nmbd server (ExecStart) for the multi-user target (WantedBy).

nmb.service

[Unit]
Description=Samba NMB Daemon
Documentation=man:nmbd(8) man:samba(7) man:smb.conf(5)
Wants=network-online.target
After=network.target network-online.target

[Service]
Type=notify
NotifyAccess=all
PIDFile=/run/nmbd.pid
EnvironmentFile=-/etc/sysconfig/samba
ExecStart=/usr/sbin/nmbd --foreground --no-process-group $NMBDOPTIONS
ExecReload=/bin/kill -HUP $MAINPID
LimitCORE=infinity
Environment=KRB5CCNAME=/run/samba/krb5cc_samba
[Install]
WantedBy=multi-user.target

Configuring Samba Access from Windows

To set up a connection for a Windows client, you need to specify the Windows workgroup name and configure the password. The workgroup name is the name that appears for the network on Windows. The default may be WORKGROUP or MSHOME. You can set up your own workgroup name, but all your computers would have to be configured to use that name.

On your Fedora Samba server, you specify the network name by manually enter it in the smb.conf file, you specify the workgroup name in the workgroup= entry in the global section. The workgroup name should be uppercase and contain no spaces. The default name used on Windows systems is simple WORKGROUP. The smb.conf workgroup entry would then look like this:

workgroup = WORKGROUP

Accessing Samba Shares from Windows

On a Windows client, you see the Samba server listed when you open the Network window on any Windows file manager window. The Samba server will have as a name the description you gave it in your Samba configuration. To access the share, the user will be required to enter the username and the Samba password. You have the option of having the username and password remembered for automatic access.

You may also need to make sure that your Windows system has enabled TCP/IP networking. This may already be the case if your Windows client is connected to a Microsoft network. If you need to connect a Windows system directly to a TCP/IP network that your Linux Samba server is running on, you should check that TCP/IP networking is enabled on that Windows system. This involves making sure that the Microsoft Network client and the TCP/IP protocol are installed, and that your network interface card (NIC adapter) is configured to use TCP/IP.

Accessing Samba shares from Windows is an issue for Windows 10. Upgrades to Windows 10 has disabled the SMBv1 network browsing capabilities of Windows, as it transitions to SMBv3 from SMBv1. You could try to manually re-enable SMBv1 browsing, but SMBv1 is being disabled due to security issues. It is not advisable to re-enable it. This means you cannot simply browse a Linux host currently, but you can still easily set up access to each Samba shared folder on that Linux host.

It is still easy to access your Samba Linux shares from Windows 10. You can simply add a new network location for it, that will be accessible from a shortcut you can set up for it on your Windows file manager "This PC" folder. To set up the shortcut, open the Windows file manager to any folder and right-click on the "This PC" entry in the sidebar to display a menu. Click on the "Add a network location" entry to open the "Add Network Location Wizard" and click Next. Click on the "Choose a custom network location" entry and click Next.  In the text box labelled "Internet or network address:" enter the host name of your Linux system that holds the shares you want to access, beginning with the two backward slashes and followed by a backward slash (you may have to also enter the name of one of the shared folders on that system).

\\richard-laptop\

You can then click the Browse button to open a dialog showing a tree of all the shared folders on that host. You can choose a share, or any of a share's subfolders. Their file pathname is automatically added to the address textbox. Alternatively, you could enter the folder path name in the text box directly with the subfolders separated by single backward slashes. If you are sharing your Linux home directories, then the shared folder is the name of the user's Home folder, the user name. Samples are shown here.

\\richard-laptop\richard
\\richard-laptop\richard\Pictures
\\richard-laptop\mydocs

Once the locations for your shared folders are set up in Windows, you can access them again quickly from their shortcuts in the "This PC" folder.

User Level Security

Samba primarily provides user level security, requiring users on remote systems to log in using Samba registered passwords. Samba still provides share and server level access, but these methods have been deprecated and are not recommended. User level security requires the use of Windows encrypted passwords. Windows uses its own methods of encryption. For Samba to handle such passwords, it has to maintain its own Windows compatible password database. It cannot use the Linux password databases. Windows also uses additional information for the login process like where the user logged in.

User level security requires that each user that wants to login to a Samba share from a Windows system has to have a corresponding user account on the Samba server. In addition, this account has to have a separate Samba password with which to log in to the Samba share. In effect, they become Samba users.

The account on the Samba server does not have to have the same name as the one on the Windows system. A Windows user name can be specified for a Samba user. This mapping of windows users to Samba (Linux) users is listed in the /etc/smbusers file. The following maps the Windows user rpetersen to the Samba (Linux) user richard.

richard = rpetersen

When the Windows user in Windows tries to access the Samba share, the user will be prompt to login. The Windows user would then enter rpetersen as the user name and the Samba password that was set up for richard.

User level security is managed by password backend databases. By default, the tdbsam back-end database is used. This is a tdb database file (trivial database) that stores Samba passwords along with Windows extended information. The tdbsam database is designed for small networks. For systems using LDAP to manage users, you can use the LDAP enabled back end, ldbsam. The ldbsam database is designed for larger networks. The smbpasswd file previously used, is still available, but included only for backward compatibility. The default configuration entries for user access in the smb.conf file are shown here.

security = user
passdb backend = tdbsam

The username map option specifies the file used to associate Windows and Linux users. Windows users can use the Windows user name to log in as the associated user. The username map file is usually /etc/samba/smbusers.

username map = /etc/samba/smbusers

Be sure to enable PAM in the smb.conf file:

obey pam restrictions = yes

If you are using an LDAP-enabled Samba database, ldbsam, you would use special LDAP Samba tools to manage users. These are provided in the smbldap-tools package. They are prefixed with the term smbldap. There are tools for adding, modifying, and deleting users and groups like smbldap-useradd, smbldap-userdelete, and smbldap-groupmod. You use the smbldap-passwd command to manage Samba passwords with LDAP. The smdbldap-userinfo obtains information about a user. You configure your LDAP Samba tools support using the /etc/smbldap-tools/smbldap.conf file.

Samba also provides its own Samba authentication PAM module for domain logons, pam_smb_auth.so (pam_smb package). Configuration is set up in the /etc/pam_smb.conf file where you specify your domain and login servers.

smbpasswd

With user-level security, access to Samba server resources by a Windows client is allowed only to users on that client. The username and Samba password used to access the Samba server has to be registered in the Samba password database.

To manage users you can use the smbpasswd command or the pdbedit tool. The smbpasswd command will work on both the older smbpasswd files and the backend databases like tdbsam. The pdbedit command works only on the backend databases.

Alternatively, you can use the smbpasswd command in a terminal window to add, or later change, passwords. The smbpasswd command with the -a option with add a user and the -x option will remove one. To enable or disable users you would use the -e and -d options.

smbpasswd -a aleina 

Users can use smbpasswd to change their own password. The following example shows how you would use smbpasswd to change your Samba password. If the user has no Samba password, that user can just press the enter key.

smbpasswd
Old SMB password: old-password
New SMB Password: new-password
Repeat New SMB Password: new-password

Should you want to use no passwords, you can use smbpasswd with the -n option. The smb.conf file will have to have the null passwords option set to yes. Note: If you are using the older smbpasswords file, be sure that Samba is configured to use encrypted passwords. Set the encrypt passwords option to yes and specify the SMB password file.

pdbedit

pdbedit is a command line tool with options for adding and removing users, as well as features like changing the password and setting the home directory. You can also import or export the user entries to or from other backend databases. It operates just on the backend database files like tdbsam, not on the older smbpasswd files.

To add a user you would use the -a option and to remove a user you use the -x option.

pdbedit -a larisa

The pdbedit command lets you display more information about users. To display users from the backend database you could use the -L option. Add the -v option for detailed information. For a particular user add the username.

pdbedit -Lv richard

For domain policies like minimum password length or retries, you use the -P option.

pdbedit -P

You use the -i and -e options to import and export database entries. The following will import entries from the old smbpasswd file to the new tdbsam backend database.

pdbedit -i smbpasswd -e tdbsam

If your system is using LDAP enabled Samba database, then use the smbldap tools to manage users and groups.

The Samba smb.conf Configuration File

Samba configuration is held in the smb.conf file located in the /etc/samba directory. You can manually edit the file directly, creating your own Samba configuration. You may have to do this if your Samba configuration proves to be very complex. Direct editing can also provide more refined control over your shares. The smb.conf.example file is a copy of the smb.conf with standard default setting, including detailed comments.

You use the testparm command to check the syntax of any changes you have made to the /etc/samba/smb.conf file. Run the following in a terminal window.

testparm

The file is separated into two basic parts: one for global options and the other for shared services. A shared service, also known as shares, can either be file space services (used by clients as an extension of their native file systems) or printable services (used by clients to access print services on the host running the server). The file space service is a directory to which clients are given access; they can use the space in it as an extension of their local file system. A printable service provides access by clients to print services, such as printers managed by the Samba server.

The /etc/samba/smb.conf file holds the configuration for the various shared resources, as well as global options that apply to all resources. Linux installs a smb.conf file in your /etc/samba directory. The file contains default settings used for your distribution. You can edit the file to customize your configuration to your own needs. Many entries are commented with either a semicolon or a # sign, and you can remove the initial comment symbol to make them effective. For a complete listing of the Samba configuration parameters, check the Man page for smb.conf.

In the smb.conf file, global options are set first, followed by each shared resource’s configuration. The basic organizing component of the smb.conf file is called a section. Each resource has its own section that holds its service name and definitions of its attributes. Even global options are placed in a section of their own, labeled global. For example, each section for a shared directory consists of the directory and the access rights allowed to users of the directory. The section of each share is labeled with the name of the shared resource. Special sections called printers and homes, provide default descriptions for user directories and printers accessible on the Samba server. Following the special sections, sections are entered for specific services, namely access to specific directories or printers.

A section begins with a section label consisting of the name of the shared resource encased in brackets. Other than the special sections, the section label can be any name you want to give it. Following the section label, on separate lines, different parameters for this service are entered. The parameters define the access rights to be granted to the user of the service. For example, for a directory, you may want it to be browseable, but read-only, and to use a certain printer. Parameters are entered in the format parameter name = value. You can enter a comment by placing a semicolon at the beginning of the comment line.

A simple example of a section configuration follows. The section label is encased in brackets and followed by two parameter entries. The path parameter specifies the directory to which access is allowed. The writeable parameter specifies whether the user has write access to this directory.

[mysection]
path = /home/chris
writeable = true

A printer service has the same format but requires certain other parameters. The path parameter specifies the location of the printer spool directory. The read-only and printable parameters are set to true, indicating the service is read-only and printable. The guest ok option indicates anyone can access it.

[myprinter]
path = /var/spool/samba
read only = yes
printable = yes
guest ok = yes

Parameter entries are often synonymous but different entries that have the same meaning. For example, read only = no, writeable = yes, and write ok = yes all mean the same thing, providing write access to the user.

Hint: The writeable option is an alias for the inverse of the read only option. The writeable = yes entry is the same as read only = no entry.

Global Section

The Global section determines the configuration for the entire server, as well as specifying default entries to be used in the home and directory sections. In this section, you find entries for the workgroup name, password configuration, and directory settings. The Global section begins with the [global] label.

[global]

Several of the more important entries are discussed here. The Global section is organized into several segments, each with a commented heading, like Network Related Options.  All are part of the [global] section.

Samba provides support for the SMB2 protocol used by Windows. Enable it by setting the max protocol option to SMB2.

max protocol = SMB2

Network related options

The Network related options begin with a commented section describing each option followed by the option entries.  Comments are commented with a preceding #, and actual options are commented with a preceding ;.

# ----------------------- Network Related Options -------------------------
#
# workgroup = NT-Domain-Name or Workgroup-Name, eg: MIDEARTH
#
# server string is the equivalent of the NT Description field
#
# netbios name can be used to specify a server name not tied to the hostname
#
# Interfaces lets you configure Samba to use multiple interfaces
# If you have multiple network interfaces then you can list the ones
# you want to listen on (never omit localhost)
# interface (lo).
#
# hosts allow = the hosts allowed to connect. This option can also be used on a
# per-share basis.

# hosts deny = the hosts not allowed to connect. This option can also be used on
# a per-share basis.
#
# max protocol = used to define the supported protocol. The default is NT1. You
# can set it to SMB2 if you want experimental SMB2 support.
#
     workgroup = MYGROUP
     server string = Samba Server Version %v

;     netbios name = MYSERVER

;     interfaces = lo eth0 192.168.12.2/24 192.168.13.2/24
;     hosts allow = 127. 192.168.12. 192.168.13.

The Workgroup entry specifies the workgroup name you want to give to your network. This is the workgroup name that appears on the Windows client’s Network window. The default Workgroup entry in the smb.conf file is shown here:

# workgroup = NT-Domain-Name or Workgroup-Name
workgroup = WORKGROUP

The workgroup name has to be the same for each Windows client that the Samba server supports. On a Windows client, the workgroup name is usually found in the System tool located in the Control Panel window. On many clients, this is defaulted to WORKGROUP. If you want to change this name, you have to change the Workgroup entry in the smb.conf file accordingly. The Workgroup entry and the workgroup name on each Windows client have to be the same. In this example the workgroup name is mygroup.

workgroup = mygroup

The server string entry, shown here, holds the descriptive name you want displayed for the server on the client systems. On Windows systems, this is the name displayed on the Samba server icon.

# server string is the equivalent of the NT Description field
     server string = Samba Server Version %v

The default is Samba Server, but you can change this to any name you want.  Here the %h variable is used to display the server's host name. 

    server string = %h server (Samba, Fedora)

As a security measure, you can restrict access to SMB services to certain specified local networks. For the hosts allow option, enter the network addresses of the local networks for which you want to permit access. To deny access to everyone in a network except a few particular hosts, you can use the EXCEPT option after the network address with the IP addresses of those hosts. The localhost (127) is always automatically included. The next example allows access to two local networks:

hosts allow = 127. 192.168.1. 192.168.2.

To use the new SMB2 protocol, you can set max protocol to SMB2.

Note: You can also configure Samba to be a Primary Domain Controller (PDC) for Windows NT networks. As a PDC, Samba sets up the Windows domain that other systems will use, instead of participating in an already established workgroup.

Logging Options

This section has directives for setting up logging for the Samba server. The log file directive is configured with the %m substitution symbol so that a separate log file is set up for each machine that connects to the server.  Logging is managed by the journald daemon.

log file = /var/log/samba/log.%m

The maximum size of a log file is set to 1000 lines.

max log size = 50

Standalone Server Options

# ----------------------- Standalone Server Options ------------------------
#
# security = the mode Samba runs in. This can be set to user, share
# (deprecated), or server (deprecated).
#
# passdb backend = the backend used to store user information in. New
# installations should use either tdbsam or ldapsam. No additional configuration
# is required for tdbsam. The "smbpasswd" utility is available for backwards
# compatibility.
#

     security = user
     passdb backend = tdbsam

Samba resources are normally accessed with either share or user-level security. On a share level, any user can access the resource without having to log in to the server. On a user level, each user has to log in, using a password. Windows clients use encrypted passwords for the login process. Passwords are encrypted by default and managed by the password database. In the following entries, the security is set to the user level (user option), and the password database file (passdb backend ) uses tdbsam.

security = user
passdb backend = tdbsam

If you want share-level security, specify share as the security option. However, this option is deprecated. User level security is considered the standard:

security = share

Domain Members Options

If your network handles authentication centrally through a domain server, then your Samba server needs to become a domain member. Domain membership is normally handled by an Active Directory Server  (ads option) or a specific PDC server (domain option). To configure the smb.conf file for domain membership, the security option is set to domain or ads. If you choose domain, then the workgroup option is set to the name of the domain.

security = domain
workgroup = mydomain

In the Domain Members Options section of the smb.conf file, you can set the realm or password server options. If security is set to ads, you can set the realm option (Active Directory Realm). If you set security to domain you use the password server option to specify the Windows PDC server your network uses. Using an asterisk (*) instead of the PDC name lets Samba detect the PDC server automatically. 

;realm = MY_REALM
;password server = <NT-Server-Name>

Name Resolution

Name service resolution is normally provided by the WINS server (Windows NetBIOS Name Service, nmbd), which is started by a samba systemd dependency. If your local network already has a WINS server, you can specify that instead. The commented default entry is shown here. Replace w.x.y.z with your network's WINS server name.

;   wins server = w.x.y.z

WINS server support by your Samba nmbd server is commented out to avoid conflicts, turning your Samba name resolution server into just a client. The commented entry to turn on WINS support is shown here.

;   wins support = yes

#----------------------------- Name Resolution -------------------------------
# This section details the support for the Windows Internet Name Service (WINS).
#
# Note: Samba can be either a WINS server or a WINS client, but not both.
#
# wins support = when set to yes, the NMBD component of Samba enables its WINS
# server.
#
# wins server = tells the NMBD component of Samba to be a WINS client.
#
# wins proxy = when set to yes, Samba answers name resolution queries on behalf
# of a non WINS capable client. For this to work, there must be at least one
# WINS server on the network. The default is no.
#
# dns proxy = when set to yes, Samba attempts to resolve NetBIOS names via DNS
# nslookups.

;wins support = yes
;wins server = w.x.y.z
;wins proxy = yes

;dns proxy = yes

If you network also has its own DNS server that it wants to use for name resolution, you can enable that instead. By default, this is commented out as shown here. Remove the comment symbol to allow the use of your network's DNS server for Windows name resolution. Also, WINS server support would have to be turned off.

;  dns proxy = yes

Name resolution can also be instructed to check the lmhosts and /etc/hosts files first.  The commented default entry is shown here.

;   name resolve order = lmhosts host wins bcast

Printing Options

# --------------------------- Printing Options -----------------------------
#
#
# The options in this section allow you to configure a non-default printing
# system.
#
# load printers = when set you yes, the list of printers is automatically
# loaded, rather than setting them up individually.
#
# cups options = allows you to pass options to the CUPS library. Setting this
# option to raw, for example, allows you to use drivers on your Windows clients.
#
# printcap name = used to specify an alternative printcap file.
#    
     load printers = yes
     cups options = raw

;     printcap name = /etc/printcap
     #obtain list of printers automatically on UNIX System V systems:
;     printcap name = lpstat
;     printing = cups

To enable printing, set the load printers option to yes.

load printers = yes

Other options like printing let you specify a different printing server (CUPS is the default).

printing = cups

File System Options

The File System Options segment lists options for file systems that support extended attributes and support for guest accounts. Normally access to certain types of files can be blocked such as archive, hidden files, read only files, and system files. Access to extended attributes can be enabled.

;     map archive = no
;     map hidden = no
;     map read only = no
;     map system = no
;     store dos attributes = yes

You can use a guest user login to make resources available to anyone without requiring a password. A guest user login would handle any users who log in without a specific account. On Linux systems, by default Samba will use the nobody user as the guest user. Alternatively, you can set up and designate a specific user to use as the guest user. Be sure to add the guest user to the password file. You designate the guest user with the guest account entry in the smb.conf file.

guest account = nobody

Homes Section

The Homes section specifies default controls for accessing a user home directory through the SMB protocols by remote users. Setting the browseable option to no prevents the client from listing the files in a file browser. The writable option specifies whether users have read and write control over files in their home directories. The create mask and directory mask options set maximum default permissions for new files and directories. The valid users option uses the %S macro to map to the current service.

[homes]
comment = Home Directories
browseable = no
writable = yes
valid users = %S
valid users = MYDOMAIN\%S

 The printer and print$ Sections

The printers section specifies the default controls for accessing printers. These are used for printers for which no specific sections exist. Setting browseable to no simply hides the Printers section from the client, not the printers. The path entry specifies the location of the spool directory Samba will use for printer files. To enable printing at all, the printable entry must be set to yes. To allow guest users to print, set the guest ok entry to yes. This specifies the command the server actually uses to print documents. The standard implementation of the Printers section is shown here:

[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
guest ok = yes
writable = no
printable = yes

Shares

Sections for specific shared resources, such as directories on your system, are usually placed after the Homes and Printers sections. For a section defining a shared directory, enter a label for the system. Then, on separate lines, enter options for its pathname and the different permissions you want to set. For the path option specify the full pathname for the directory. The comment option holds the label to be given the share. You can make a directory writable, public, or read-only. For those options not set, the defaults entered in the Global, Homes, and Printers segments are used. For more examples, check those in the original smb.conf file. The following example is the myprojects share. Here the /myprojects directory is defined as a shared resource that is open to any user with guest access.

 [myprojects]
     comment = Great Project Ideas
     path = /myprojects
     read only = no
     guest ok = yes

To allow complete public access, set the guest ok option to yes, with no valid user’s entry (use this instead of the public option).

 [newdocs]
 comment =  New Documents
 path = /home/newdocs
 guest ok = yes
 read only = no

To limit access to certain users, you can list a set of valid users with the valid users option. Setting the guest ok option to no closes it off from access by others. The invalid users option denies access to certain users.

[mynewmusic]
 comment =  New Music
 path = /home/specialprojects
 valid users = robert george larisa aleina
 invalid users = richard mark
 guest ok = no
 read only = no

You can use the read list and write list options to control read and write access to certain users. The read list option allow read only access to files and the write list option permits read/write access. In the following example, robert and george have read only access whereas larisa and aleina have read/write access. Groups can be specified by preceding the group name with an @ symbol, @mygroup. Keep in mind that write permissions would still have to be enabled on the Linux system for those files (chmod).

[mynewpics]
 comment =  New Music
 path = /home/specialprojects writable = yes
 valid users = robert george larisa aleina
 read list = robert george
 write list = larisa aleina

To set up a directory that can be shared by more than one user, where each user has control of the files he or she creates, simply list the users in the Valid Users entry. Permissions for any created files are specified in the Advanced mode by the Create Mask entry (same as create mask). In this example, the permissions are set to 765, which provides read/write/execute access to owners, read/write access to members of the group, and only read/execute access to all others (the default is 744, read-only for group and other permissions):

[myshare]
comment = Writer’s projects
path = /usr/local/drafts
valid users = justin chris dylan
writable = yes
guest ok = no
read only = no
create mask = 0765

Printers

Access to specific printers is defined in the Printers section of the smb.conf file. For a printer, you need to include the Printer and Printable entries, as well as specify the type of Printing server used. With the Printer entry, you name the printer, and by setting the Printable entry to yes, you allow it to print. You can control access to specific users with the valid users entry and by setting the Public entry to no. For public access, set the public entry to yes. For the CUPS server, set the printing option cups.

The following example sets up a printer accessible to guest users. This opens the printer to use by any user on the network. Users need to have write access to the printer’s spool directory, located in /var/spool/samba. Keep in mind that any printer has to first be installed on your system. The following printer was already installed as myhp. You use the CUPS administrative tool to set up printers for the CUPS server. The Printing option can be inherited from general Printers share.

[myhp]
      path = /var/spool/samba
      read only = no
      guest ok = yes
      printable = yes
      printer = myhp
      oplocks = no
      share modes = no
      printing = cups

As with shares, you can restrict a printer's use to certain users, denying it to public access. The following example sets up a printer accessible only by the users larisa and aleina (you could add other users if you want). Users need to have write access to the printer’s spool directory.

 [larisalaser]

      path = /var/spool/samba
      read only = no
      valid users = larisa aleina
      guest ok = no
      printable = yes
      printing = cups
      printer = larisalaser
      oplocks = no
      share modes = no

Variable Substitutions

For string values assigned to parameters, you can incorporate substitution operators. This provides greater flexibility in designating values that may be context-dependent, such as usernames. For example, suppose a service needs to use a separate directory for each user who logs in. The path for such directories could be specified using the %u variable that substitutes in the name of the current user. The string path = /tmp/%u would become path = /tmp/justin for the justin user and /tmp/dylan for the dylan user. Table 12-3 lists several of the more common substitution variables.

Variable

Description

%S

Name of the current service

%P

Root directory of the current service

%u

Username of the current service

%H

Home directory of the user

%h

Internet hostname on which Samba is running

%m

NetBIOS name of the client machine

%L

NetBIOS name of the server

%M

Internet name of the client machine

%I

IP address of the client machine

 Table 12-3: Samba Substitution Variables

Testing the Samba Configuration

After you make your changes to the smb.conf file, you can then use the testparm program to see if the entries are correctly entered. testparm checks the syntax and validity of Samba entries. By default, testparm checks the /etc/samba/smb.conf file. If you are using a different file as your configuration file, you can specify it as an argument to testparm. You can also have testparm check to see if a particular host has access to the service set up by the configuration file.

To check the real-time operation of your Samba server, you can log in to a user account on the Linux system running the Samba server and connect to the server.

Samba Public Domain Controller: Samba PDC

Samba can also operate as a Public Domain Controller (PDC). The domain controller will be registered and advertised on the network as the domain controller. The PDC provides a much more centralized way to control access to Samba shares. It provides the netlogon service and a NETLOGON share. The PDC will set up machine trust accounts for each Windows and Samba client. Though you can do this manually, Samba will do it for you automatically. You can find out more about Samba PDC at:

https://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection/samba-pdc.html

Microsoft Domain Security

As noted in the Samba documentation, the primary benefit of Microsoft domain security is single-sign-on (SSO). In effect, logging into your user account also logs you into access to your entire network's shared resources. Instead of having to be separately authenticated anytime you try to access a shared network resource, you are already authenticated. Authentication is managed using Security IDs (SID) that consists of a network ID (NID) and a relative ID (RID). The RID references your personal account. A separate RID is assigned to every account, even those for groups or system services. The SID is used to set up access control lists (ACL) the different shared resources on your network, allowing a resource to automatically identify you.  

Note: You can enable and configure the Samba PDC controller using system-config-authentication (Applications overview, Other filter).  On the Identity & Authorization tab, choose Winbind from the User Account Database drop down menu to display entries where you can enter the workgroup and the domain controller URL (PDC).

Essential Samba PDC configuration options

To configure your PDC edit the Domain Control Options section in the smb.conf file. Here you will find entries for configuring your Samba PDC.

The essential PDC options are shown here.

netbios name = mysystem
workgroup = myworkgroup
security = user
domain master = yes
domain logons = yes

Basic configuration

The netbios name is the name you want to give to the PDC server.

netbios name = MYSERVER

Like most Samba configurations, the PDC requires a Samba backend. The tdbsam is already configured for you. The security level should be user. This is normally the default and should already be set. The smb.conf entries are shown here:

security = user
passdb backend = tdbsam

Domain Logon configuration

Samba PDC uses domain logons service whereby a user can log on to the network. The domain logon service is called the netlogon service by Microsoft. The samba share it uses is also called netlogon. To configure the domain logon service you set the domain logons entry to yes. The PDC must also be designated the domain master. These are located in the [global] section of your smb.conf file, in the Domain Controller Options segment. The entries are commented with preceding semicolon, ;. Remove the semi-colon to uncomment them, making them active. The entries are already set to yes.

domain master = yes
domain logons = yes

The login script can be one set by the system or by users. The logon path references the profile used for a user.

# the login script name depends on the machine name
logon script = %m.bat
# the login script name depends on the unix user used
logon script = %u.bat
logon path = \\%L\Profiles\%u

You can then enable user add and delete operations for adding and removed users from the PDC. The add machine entry allows Samba to automatically add trusted machine accounts for Windows systems when they first join the PDC controlled network.

add user script = /usr/sbin/useradd "%u" -n -g users
add group script = /usr/sbin/groupadd "%g"
add machine script = /usr/sbin/useradd -n -c "Workstation (%u)" -M -d /nohome -s /bin/false "%u"
delete user script = /usr/sbin/userdel "%u"
delete user from group script = /usr/sbin/userdel "%u" "%g"
delete group script = /usr/sbin/groupdel "%g"

You then need to set up a netlogon share in the smb.conf file. Find the section labeled [netlogon]. This share holds the netlogon scripts, in this case, the /var/lib/samba/netlogon directory, which should not be writable but should be accessible by all users (Guest OK). In the share definitions section of the smb.conf file, you will find the [netlogon] section commented. Remove the semi-colon comments from the entry, as shown here.

# Un-comment the following and create the netlogon directory for Domain Logon
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon
guest ok = yes
writable = no
share modes = no

If you are using profiles, you should add the roving profile share([Profiles] label). Add the following to provide a specific roving profile share, located just after the netlogon shares. The profile share is where user netlogon profiles are stored.

# the default is to use the user's home directory
[Profiles]
path = /var/lib/samba/profiles
browseable = no
guest ok = yes

Master Browser configuration

The PDC has browser functionality, with which it locates systems and shares on your network. Browser features are set in the Browser Control Options section of the smb.conf. The local master option is used only if you already have another PDC that you want to operate as the local master. Normally you would leave the entry commented, as shown here. You could have several domain controllers operating on your network. Your Microsoft network holds an election choose which should be the master. The os level sets the precedence for this PDC. It should be higher than 32 to gain preference over other domain controllers on your network, ensuring this PDC's election as the primary master controller. The preferred master option starts the browser election on startup.

;     local master = no
;     os level = 33
;     preferred master = yes

Accessing Samba Services with Clients

Client systems connected to the SMB network can access the shared services provided by the Samba server. Windows clients should be able to access shared directories and services automatically on a Windows desktop. For Linux systems connected to the same network, Samba services can be accessed using the GNOME file manager or the KDE file manager, as well as special Samba client programs. 

With the Samba smbclient, a command line client, a local Linux system can connect to a shared directory on the Samba server and transfer files, as well as run shell programs (samba-clients package). Using the mount command with the -t cifs option, directories on the Samba server can be mounted to local directories on the Linux client. The cifs option invokes mount.cifs to mount the directory.

 Accessing Windows Samba Shares from GNOME

You can use Nautilus (the GNOME file manager) to access your Samba shares. On the GNOME file manager choose Network to open a Network window, which displays the icons for your network. The Windows Network icon will hold the Windows workgroups that your Windows hosts are part of. Opening up the Windows Network icon will list your Windows network groups, like WORKGROUP. Opening up the Windows group icon will list the hosts in that group. These will show host icon for your shared Windows hosts. Clicking a host icon will list all the shared resources on it.

Alternatively, you can open a location entry in a file manager window (Go | Location) and enter the smb: protocol to display all the Samba and Windows networks, from which you can access the Samba and Windows shares.

smbclient

The smbclient utility operates like FTP to access systems using the SMB protocols. Whereas with an FTP client you can access other FTP servers or Unix systems, with smbclient you can access SMB-shared services, either on the Samba server or on Windows systems. Many smbclient commands are similar to FTP, such as mget to transfer a file or del to delete a file. The smbclient program has several options for querying a remote system, as well as connecting to it. See the smbclient Man page for a complete list of options and commands. The smbclient program takes as its argument a server name and the service you want to access on that server. A double slash precedes the server name, and a single slash separates it from the service. The service can be any shared resource, such as a directory or a printer. The server name is its NetBIOS name, which may or may not be the same as its IP name. For example, to specify the myreports shared directory on the server named turtle.mytrek.com, use //turtle.mytrek.com/myreports.

//server-name/service

You can also supply the password for accessing the service. Enter it as an argument following the service name. If you do not supply the password, you are prompted to enter it.

You can then add several options to access shares, such as the remote username or the list of services available. With the -I option, you can specify the system using its IP address. You use the -U option and a login name for the remote login name you want to use on the remote system. Attach % with the password if a password is required. With the -L option, you can obtain a list of the services provided on a server, such as shared directories or printers. The following command will list the shares available on the host turtle.mytrek.com:

smbclient -L turtle.mytrek.com

To access a particular directory on a remote system, enter the directory as an argument to the smbclient command, followed by any options. For Windows files, you use backslashes for the pathnames, and for Unix/Linux files, you use forward slashes. Once connected, an SMB prompt is displayed and you can use smbclient commands such as get and put to transfer files. The quit or exit commands quit the smbclient program. In the following example, smbclient accesses the directory myreports on the turtle.mytrek.com system, using the dylan login name:

smbclient //turtle.mytrek.com/myreports -I 192.168.0.1 -U dylan

In most cases, you can simply use the server name to reference the server, as shown here:

smbclient //turtle.mytrek.com/myreports -U dylan

If you are accessing the home directory of a particular account on the Samba server, you can simply specify the homes service. In the next example, the user accesses the home directory of the aleina account on the Samba server, after being prompted to enter that account’s password:

smbclient //turtle.mytrek.com/homes -U aleina

You can also use smbclient to access shared resources located on Windows clients. Specify the computer name of the Windows client along with its shared folder. In the next example, the user accesses the windata folder on the Windows client named lizard. The folder is configured to allow access by anyone, so the user just presses the enter key at the password prompt.

smbclient //lizard/windata

Once logged in, you can execute smbclient commands to manage files and change directories. Shell commands can be executed with the ! operator. To transfer files, you can use the mget and mput commands, much as they are used in the FTP program.

mount.cifs: mount -t cifs

Using the mount command with the -t cifs option, a Linux client can mount a shared directory onto its local system. The cifs option invokes the mount.cifs command to perform the mount operation. The syntax for the mount.cifs command is similar to that for the smbclient command, with many corresponding options. The mount.cifs command takes as its arguments the Samba server and shared directory, followed by the local directory where you want to mount the directory. T

Instead of using mount.cifs explicitly, you use the mount command with the file system type cifs. This will then run the /sbin/mount.cifs command, which will invoke smbclient to mount the file system:

mount -t cifs //turtle.mytrek.com/myreports /mnt/myreps -U dylan

To unmount the directory, use the cifs.umount command with the local directory name, as shown here:

cifs.umount /mnt/myreps

To mount the home directory of a particular user on the server, specify the homes service and the user’s login name. The following example mounts the home directory of the user larisa to the /home/chris/larisastuff directory on the local system:

mount -t samba //turtle.mytrek.com/homes /home/chris/larisastuff -U larisa

You can also mount shared folders on Windows clients. Just specify the computer name of the Windows client along with its folder. If the folder name contains spaces, enclose it in single quotes. In the following example, the user mounts the windata folder on lizard as the /mylinux directory. For a folder with access to anyone, just press enter at the password prompt:

$ mount -t cifs //lizard/windata  /mylinux
Password:
$ ls /mylinux
_hi_mynewdoc.doc_myreport.txt

To unmount the shared folder when you are finished with it, use the cifs.umount command.

cifs.umount /mylinux

You could also specify a username and password as options if user-level access is required:

mount -t cifs -o username=chris passwd=mypass //lizard/windata /mylinux

You can also use the cifs type in an /etc/fstab entry to have a Samba file system mounted automatically:

//lizard/windata /mylinux cifs defaults 0 0

13. Distributed Network File Systems

For very large distributed systems like Linux clusters, Linux also supports distributed network file systems, such as Oracle Cluster File System for Linux (OCFS2), Lustre, the Gluster Storage Platform (GlusterFS), and Red Hat Global File System (GFS and GFS 2). These systems build on the basic concept of NFS as well as RAID techniques to create a file system implemented on multiple hosts across a large network, in effect, distributing the same file system among different hosts at a very low level (see Table 13-1). You can think of it as a kind of RAID array implemented across network hosts instead of just a single system. Instead of each host relying on its own file systems on its own hard drive, they all share the same distributed file system that uses hard drives collected on different distributed servers. This provides far more efficient use of storage available to the hosts, as well as providing for more centralized management of file system use.

Website

Name

https://fedoraproject.org/wiki/Features/Cluster

Fedora Cluster status and links

https://corosync.github.io/corosync/

Corosync Cluster Engine

https://wiki.clusterlabs.org/wiki/Pacemaker

Pacemaker cluster services and PCS documentation

https://oss.oracle.com/projects/ocfs2/

OCFS2, Oracle Cluster File System for Linux

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/high_availability_add-on_overview/index

Red Hat High Availability Addon

https://www.gluster.org

Gluster Storage Platform

https://wiki.lustre.org

Lustre cluster file system

 Table 13-1: Distributed File Systems

A distributed network file system builds on the basic concept of NFS as well as RAID techniques to create a file system implemented on multiple hosts across a large network, in effect, distributing the same file system among different hosts at a very low level. You can think of it as a kind of RAID array implemented across network hosts instead of just a single system. That is, instead of each host relying on its own file systems on its own hard drive, they all share the same distributed file system that uses hard drives collected on different distributed servers. This provides far greater efficient use of storage available to the hosts and provides for more centralized management of file system use. GFS can be run either directly connected to a SAN (storage area network) or using GNBD (Global Network Block Device) storage connected over a LAN. The best performance is obtained from a SAN connection, whereas a GNBD format can be implemented easily using the storage on LAN (Ethernet)–connected systems. As with RAID devices, mirroring, failover, and redundancy can help protect and recover data.

The Red Hat Global File System (GFS2) is the preferred distributed file system for Fedora. GFS separates the physical implementation from the logical format. A GFS appears as a set of logical volumes on one seamless logical device that can be mounted easily to any directory on your Linux file system. The logical volumes are created and managed by the Cluster Logical Volume Manager (CLVM), which is a cluster-enabled LVM. Physically, the file system is constructed from different storage resources, known as cluster nodes, distributed across your network. The administrator manages these nodes, providing needed mirroring or storage expansion. Should a node fail, GFS can fence a system off until it has recovered the node. Setting up a GFS requires planning. You have to determine ahead of time different settings like the number and names of your Global File Systems, the nodes that will be able to mount the file systems, fencing methods, and the partitions and disks to use.

The Red Hat Global File System (GFS2), the Gluster Storage Platform (GlusterFS), and the Oracle Cluster File System for Linux (OCFS2) are available from the Fedora repository. GlusterFS is open source and freely available, though support can be purchased commercially. On Fedora, it is installed with the glusterfs-server, glusterfs-common, and glusterfs-client packages. See the GlusterFS site for more details, https://www.gluster.org, and commercial support is available at https://www.gluster.com. Configuration is located at /etc/glusterfs.  Detailed examples are located in the /usr/share/doc/glusterfs-server directory.

The OCFS2 cluster file system is provided by Oracle as open source software. You can install it with the ocfs2-tools and ocfs2-tools-cman packages. The ocfs2console package installs a graphical management interface which you can run with the ocfs2console command in a terminal window. You can use it to configure, mount, format, and check your OCFS2 file systems. You can find out more about OCFS2 at https://oss.oracle.com/projects/ocfs2/.

Note: OrangeFS is the current implementation of the Parallel Virtual File System (PVFS), which implements a distributed network file system using a management server that manages the files system on different I/O servers. Management servers maintain the file system information, including access permissions, directory structure, and metadata information, https://www.orangefs.org. You can install it with the orangefs packages.

Corosync Cluster Engine

The Corosync Cluster Engine is a "user space kernel" for clustering services. It provides the basis of communication, membership, and other services used in clustering environments., www.corosync.org. This is an open source Linux project. Fedora provides Fedora compliant binaries in the corosync and corosynclib packages. Corosync packages include corosync, corosync-cfgtool (a configuration tool), and corosync-keygen. Corosync is managed by systemd using the corosync.service unit file, which starts the Corosync service for the multi-user.target using the corosync script located at /usr/share/corosync. You can use the systemctl command to start and stop corosync.

It separates the core infrastructure from the clustering services. Derived from the OpenAIS project, Corosync provides the underlying cluster infrastructure rather than API. 

You can find out more about Corosync at:

https://corosync.github.io/corosync/

Corosync is a plug-in cluster engine with a modular design.  Modules, known as service engines, are plugged into the Corosync engine to make use of Corosync cluster services. Corosync components include Totem communications protocol which is based on the OpenAIS virtual synchrony communications model, a live component replacement (LCR) plugin system, an object database for the service engines and their configuration, a logging system, and inter-process communications (IPC) manager. Service engine modules include configuration for LDAP and corosync/openeais file format, the cluster manager (pacemaker) operates as part of corosync, both fence and fence agents.

Corosync is configured by the /etc/corosync.conf configuration file. Currently, there are four directives, forming blocks, within which options can be specified.  They are the same as those used for OpenAIS. The four directives are totem for the Totem protocol, logging, amf for the AMF service, and event for the event service. See the corosync.conf man page for a complete description of directives and options.

 Corosync uses its own protocol called Totem to perform multicast communications.  Totem configuration is specified in the totem directive of the corosync.conf file as shown here. 

totem {
     version: 2
     secauth: off
     threads: 0
     interface {
          ringnumber: 0
          bindnetaddr: 192.168.1.1
          mcastaddr: 226.94.1.1
          mcastport: 5405
     }
}

Pacemaker

To manage your clusters you use a cluster manager. The recommended one for Fedora is the Pacemaker Cluster Resource Manager (pacemaker and pcs packages). The older cman cluster manager has been deprecated. The pacemaker package installs the pacemaker service. The pcs package installs the pacemaker configuration service.  Pacemaker can work with Redhat's GFS2, Oracle's OCFS2, and with Cluster LVM (CLVM2). On Fedora, you would normally use GFS2.

Pacemaker is managed by systemd using the pacemaker.service unit file, which is generated from a pacemaker System V script in /etc/init.d. 

Once installed, you can use the Pacemaker Configuration Service (pcs) to manage your clusters. The pcs daemon is managed by systemd using the pcsd.service unit file. You can use pcs commands to setup and manage your clusters.

Check the Pacemaker Web site for detailed documentation on Pacemaker and Corosync for PCS.

https://wiki.clusterlabs.org/wiki/Pacemaker

Red Hat Global File System (GFS)

Red Hat provides the Global File System (GFS) as an open source freely available distributed network file system. The original GFS version has been replaced with the new version of GFS, GFS 2, which uses a similar set of configuration and management tools, as well as native kernel support. Instead of a variety of seemingly unrelated packages. Native kernel support for GFS 2 provides much of the kernel-level operations. GFS 2 now works through the Corosync Cluster Engine. You would use Corosync cluster commands for your cluster.  GFS2 tools have been placed in the gfs2-utils, package, and the Distributed Lock Manager (DLM) commands in the dlm package. 

Many former cluster packages and applications have been deprecated with Fedora, including cman, rgmanager, openais, heartbeat, luci, and system-config-cluster. Though lower level GFS commands are available in the gfs2-utils package, you are expected to use Corosync and Pacemaker commands to manage your clusters.

To run a cluster, you need both a cluster manager and locking mechanism. Pacemaker with the Distributed Lock Manager (dlm) implements cluster management and locking. Pacemaker manages connections between cluster devices and services, using dlm to provide locking. The dlm locking mechanism operates as a daemon with supporting libraries.

To set up a GFS 2 file system, you first need to create cluster devices using the physical volumes and organizing them into logical volumes. You use the CLVM (Clustering Logical Volume Manager) to set up logical volumes from physical partitions (in the past you used a volume manager called pool to do this). You can then install GFS file systems on these logical volumes directly. CLVM operates like LVM, using the same commands. It works over a distributed network and requires that the clvmd server is running (lvm2-cluster package).

Several GFS commands manage the file system, such as mkfs.gfs2 to make a GFS file system, fsck.gfs2to check and repair, and gfs2_grow to expand a file system. Check their respective Man pages for detailed descriptions. The GFS commands for managing GFS file systems are listed in Table 13-2.

Command

Description

dlm_tool

Distributed Lock Manager, implemented as a kernel module, invoked by the cman script

gfs2_fsck

The GFS 2 file system checker

gfs2_grow

Grows a GFS 2 file system

gfs2_jadd

Adds a journal to a GFS 2 file system

mkfs.gfs2

Makes a GFS 2 file system

gfs2_convert

Convert GFS 1 filesystem to GFS 2

gfs2_edit

Edit a GFS 2 file system

getfacl

Gets the ACL permissions for a file or directory

setfacl

Sets access control (ACL) for a file or directory

 Table 13-2: GFS2 Tools

To mount a GFS file system, you use the mount command specifying gfs2 as the mount type, as in

mount  -t gfs2  /dev/vg0/mgfs  /mygfs

This will invoke the mkfs.gfs2 tool to perform the mount operation. Several GFS-specific mount options are also available, specified with the -o option, such as lockproto to specify a different lock protocol and acl to enable ACL support .

To check the status of a file system, you can use fsck.gfs2. This tool operates much like fsck, checking for corrupt systems and attempting repairs. You must first unmount the file system before you can use fsck.gfs2 on it.

Should you add available space to the device on which a GFS file system resides, you can use gfs2_grow to expand the file system to that available space. It can be run on just one node to expand the entire cluster. If you want journaling, you first have to add journal files with the gfs2_jadd tool. gfs2_grow can only be run on a mounted GFS file system.

Journal files for GFS are installed in space outside of the GFS file system but on the same device. After creating a GFS file system, you can run gfs2_jadd to add the journal files for it. If you are expanding a current GFS file system, you need to run gfs2_jadd first. Like gfs2_grow, gfs2_jadd can only be run on mounted file systems. With the setfacl command, you can set permissions for files and directories.

To create new file systems on the cluster devices, you use the mkfs.gfs2 command and mount them with the -t gfs2 option. The following command creates a GFS file system on the /dev/gv0/mgfs and then mounts it to the /mygfs directory. For mkfs.gfs2, the -t option indicates the lock table used and the -p option specifies the lock protocol. The -j option specifies the number of journals, and the -p option specifies the lock protocol to use.

mkfs.gfs2  -t mycluster:mygfs  -p lock_dlm  -j 2   /dev/vg0/mgfs
mount -t gfs /dev/vg0/mgfs /gfs1

To have the gfs service script mount the GFS file system for you, you need to place an entry for it in the /etc/fstab file. If you do not want the file system automatically mounted, add the noauto option.

/dev/vg0/mgfs   /mygfs    gfs2   noauto,defaults   0   0

GFS also supports access controls. You can restrict access by users or groups to certain files or directories, specifying read or write permissions. With the setfacl command, you can set permissions for files and directories. You use the -m option to modify an ACL permission and -x to delete it. The getfacl obtains the current permissions for file or directory. The following sets read access by the user dylan to myfile.

setfacl -m u:dylan:r myfile

Part 4: Network Support

14. Proxy Servers: Squid

15. Domain Name System: BIND 9

16. Network Autoconfiguration with IPv6, DHCP 4

14. Proxy Servers: Squid

Proxy servers operate as an intermediary between a local network and services available on a larger one such as the Internet. Requests from local clients for web services can be handled by the proxy server, speeding transactions as well as controlling access. Proxy servers maintain current copies of commonly accessed web pages, speeding web access times by eliminating the need to access the original site constantly. They also perform security functions, protecting servers from unauthorized access.

Squid is a free, open source, proxy-caching server for web clients, designed to speed Internet access and provide security controls for web servers. It implements a proxy-caching service for web clients that caches web pages as users make requests. Copies of web pages accessed by users are kept in the Squid cache, and as requests are made, Squid checks to see if it has a current copy. If Squid does have a current copy, it returns the copy from its cache instead of querying the original site. If it does not have a current copy, it will retrieve one from the original site. Replacement algorithms periodically replace old objects in the cache. In this way, web browsers can then use the local Squid cache as a proxy HTTP server. Squid currently handles web pages supporting the HTTP, FTP, and SSL protocols (Squid cannot be used with FTP clients), each with an associated default port (see Table 14-1). It also supports ICP (Internet Cache Protocol), HTCP (Hypertext Caching Protocol) for web caching, and SNMP (Simple Network Management Protocol) for providing status information.

Protocol

Description and Port

HTTP

Web pages, port 3128

FTP

FTP transfers through websites, port 3128

ICP

Internet Caching Protocol, port 3130

HTCP

Hypertext Caching Protocol, port 4827

CARP

Cache Array Routing Protocol

SNMP

Simple Network Management Protocol, port 3401

SSL

Secure Socket Layer

 Table 14-1: Protocols Supported by Squid

You can find out more about Squid at www.squid-cache.org. For detailed information, check the Squid FAQ and the user manual located at their website. The FAQ is also installed in your /usr/share/doc under the squid directory.

As a proxy, Squid does more than just cache web objects. It operates as an intermediary between the web browsers (clients) and the servers they access. Instead of connections being made directly to the server, a client connects to the proxy server. The proxy then relays requests to the web server. This is useful for situations where a web server is placed behind a firewall server, protecting it from outside access. The proxy is accessible on the firewall, which can then transfer requests and responses back and forth between the client and the web server. The design is often used to allow web servers to operate on protected local networks and still be accessible on the Internet. You can also use a Squid proxy to provide web access to the Internet by local hosts. Instead of using a gateway providing complete access to the Internet, local hosts can use a proxy to allow them just web access. You can also combine the two, allowing gateway access, but using the proxy server to provide more control for web access. In addition, the caching capabilities of Squid can provide local hosts with faster web access.

Technically, you could use a proxy server to simply manage traffic between a web server and the clients that want to communicate with it, without doing caching at all. Squid combines both capabilities as a proxy-caching server.

Squid also provides security capabilities that let you exercise control over hosts accessing your web server. You can deny access by certain hosts and allow access by others. Squid also supports the use of encrypted protocols such as SSL. Encrypted communications are tunneled (passed through without reading) through the Squid server directly to the web server.

Squid is supported and distributed under a GNU Public License by the National Laboratory for Applied Network Research (NLANR) at the University of California, San Diego. The work is based on the Harvest Project to create a web indexing system that includes a high-performance cache daemon called cached. You can obtain current source code versions and online documentation from the Squid home page at www.squid-cache.org. The Squid software package consists of the Squid server, several support scripts for services like LDAP and HTTP, and a cache manager script called cachemgr.cgi. The cachemgr.cgi lets you view statistics for the Squid server as it runs.

Configuring Client Browsers

Squid supports both standard proxy caches and transparent caches. With a standard proxy cache, users will need to configure their browsers to specifically access the Squid server. A transparent cache, on the other hand, requires no browser configuration by users. The cache is transparent, allowing access as if it were a normal website. Transparent caches are implemented by IPtables using net filtering to intercept requests and direct them to the proxy cache.

With a standard proxy cache, users need to specify their proxy server in their web browser configuration. For this, they will need the IP address of the host running the Squid proxy server as well as the port it is using. Proxies usually make use of port 3128. To configure use of a proxy server running on the private network, you enter the following. The proxy server is running on turtle.mytrek.com (192.168.0.1) and using port 3128.

192.168.0.1 3128

On Firefox, the user on the local network goes to the Network Proxy section of the Preferences dialog and click on the Settings link.

For GNOME, the System Settings Network tab.  Click on the Network Proxy gear button to open a dialog where you can specify Automatic, Manual, and Disabled options. With the Manual option you can enter the proxy server address and port numbers.

For Konqueror on the KDE Desktop, select the "Network proxy" tab on the Preferences | Web Browsing menu window. Here, you can enter the proxy server address and port numbers.

You can also set the http_proxy and ftp_proxy shell variables to configure access by Linux-supported web browsers such as Lynx. You can place these definitions in your .bash_profile or /etc/profile file to have them automatically defined whenever you log in.

http_proxy=192.168.0.1:3128
ftp proxy=192.168.0.1:3128
export http_proxy ftp_proxy

Alternatively, you can use the proxy’s URL.

http_proxy=http://turtle.mytrek.com:3128

For the Elinks browser, you can specify a proxy in its configuration file, /etc/elinks.conf. Set both FTP and web proxy host options, as in:

protocol.http.proxy.host  turtle.mytrek.com:3128
protocol.ftp.proxy.host  turtle.mytrek.com:3128

Before a client on a local host can use the proxy server, access permission has to be given to it in the server’s squid.conf file, described in the later section “Security.” Access can easily be provided to an entire network. For the sample network used here, you would have to place the following entries in the squid.conf file. These are explained in detail in the following sections.

acl mylan src 192.168.0.0/255.255.255.0
http_access allow mylan

Tip: Web clients that need to access your Squid server as a standard proxy cache will need to know the server’s address and the port for Squid’s HTTP services, by default 3128.

Squid server configuration files

Squid server configuration files are located in the /etc/squid directory. The primary configuration file is squid.conf. The mime.conf file provides mime type associations for file types, such as associating the .tgz files with the tar application and .jpeg as an image file.  If your network uses a Windows Primary Domain Controller (PDC) server, you can specify it in the msntauth.conf file. The errorsheet.css file is a style sheet for formatting Squid error pages, letting you set features such as the font size, margins, and background color or image. The cachemgr.conf file specifies the servers managed by the cachmgr.cgi script (see the section Proxy Caches later in this chapter).

The Squid server is managed by systemd using the squid.service file, shown here. It is started for the multi-user.target (runlevels 2, 3, 4, and 5) (WantedBy). Runtime configuration is read from the /etc/sysconfig/squid file (EnvironmentFile). The /user/sbin/squid application is used to start, stop, and restart the server (ExecStart, ExecReload, ExecStop).

squid.service

[Unit]
Description=Squid caching proxy
After=network.target nss-lookup.target
[Service]
Type=forking
LimitNOFILE=16384
EnvironmentFile=/etc/sysconfig/squid
ExecStartPre=/usr/libexec/squid/cache_swap.sh
ExecStart=/usr/sbin/squid $SQUID_OPTS -f $SQUID_CONF
ExecReload=/usr/sbin/squid $SQUID_OPTS -k reconfigure -f $SQUID_CONF
ExecStop=/usr/sbin/squid -k shutdown -f $SQUID_CONF
TimeoutSec=0
[Install]
WantedBy=multi-user.target

You can use the systemctl command to manually stop, start, and restart the server, as well as enable for disable it. 

sudo systemctl enable squid
sudo systemctl start squid

The squid.conf File

The Squid server configuration file is squid.conf, located in the /etc/squid directory. A minimum set of options are listed with explanations. In the /etc/squid/squid.conf file, you set general options such as ports used, security options controlling access to the server, and cache options for configuring caching operations. You can use a backup version called /etc/squid/squid.conf.default to restore your original defaults. There are many more options you can use. See https://www.squid-cache.org/Doc/config/ for a complete list, as well as examples. Entries consist of tags that specify different attributes. For example, maximum_object_size and maximum_object set limits on objects transferred.

maximum_object_size 4096 KB

As a proxy, Squid will use certain ports for specific services, such as port 3128 for HTTP services like web browsers. Default port numbers are already set for Squid. Should you need to use other ports, you can set them in the /etc/squid/squid.conf file. The following entry shows how you set the web browser port:

http_port 3128

Squid provides a default squid.conf file with the recommended configuration shown here:

/etc/squid/squid.conf

#
# Recommended minimum configuration:
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 0.0.0.1-0.255.255.25   # RFC 1122 "this" network (LAN)
acl localnet src 10.0.0.0/8             # RFC 1918 local private network (LAN)
acl localnet src 100.64.0.0/10          # RFC 6598 shared address space (CGN)
acl localhet src 169.254.0.0/16 # RFC 3927 link-local (directly plugged) machines
acl localnet src 172.16.0.0/12          # RFC 1918 local private network (LAN)
acl localnet src 192.168.0.0/16         # RFC 1918 local private network (LAN)
acl localnet src fc00::/7               # RFC 4193 local private network range
acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines

acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210          # wais
acl Safe_ports port 1025-65535   # unregistered ports
acl Safe_ports port 280          # http-mgmt
acl Safe_ports port 488          # gss-http
acl Safe_ports port 591          # filemaker
acl Safe_ports port 777          # multiling http
acl CONNECT method CONNECT

# Recommended minimum Access Permission configuration:
#
# Deny requests to certain unsafe ports
http_access deny !Safe_ports
# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost
# And finally deny all other access to this proxy
http_access deny all
# Squid normally listens to port 3128
http_port 3128

# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/spool/squid 100 16 256
# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid
#
# Add any of your own refresh_pattern entries above these.
#
refresh_pattern ^ftp:        1440     20%     10080
refresh_pattern ^gopher:     1440     0%     1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%     0
refresh_pattern .          0     20%     4320

Proxy Security

Squid can use its role as an intermediary between web clients and a web server to implement access controls, determining who can access the web server and how. Squid does this by checking access control lists (ACLs) of hosts and domains that have had controls placed on them. When it finds a web client from one of those hosts attempting to connect to the web server, it executes the control. Squid supports a number of controls with which it can deny or allow access to the web server by the remote host’s web client (see Table 14-2). In effect, Squid sets up a firewall just for the web server.

Options

Description

src ip-address/netmask

Client’s IP address

src addr1-addr2/netmask

Range of addresses

dst ip-address/netmask

Destination IP address

myip ip-address/netmask

Local socket IP address

srcdomain domain

Reverse lookup, client IP

dstdomain domain

Destination server from URL; for dstdomain and dstdom_regex, a reverse lookup is tried if an IP-based URL is used

srcdom_regex [-i] expression

Regular expression matching client name

dstdom_regex [-i] expression

Regular expression matching destination

time [day-abbrevs] [h1:m1-h2:m2]

Time as specified by day, hour, and minutes. Day abbreviations: S = Sunday, M = Monday, T = Tuesday, W = Wednesday, H = Thursday, F = Friday, A = Saturday

url_regex [-i] expression

Regular expression matching on whole URL

urlpath_regex [-i] expression

Regular expression matching on URL path

port ports

A specific port or range of ports

proto protocol

A specific protocol, such as HTTP or FTP

method method

Specific methods, such as GET and POST

browser [-i] regexp

Pattern match on user-agent header

ident username

String match on ident output

src_as number

Used for routing of requests to specific caches

dst_as number

Used for routing of requests to specific caches

proxy_auth username

List of valid usernames

snmp_community string

A community string to limit access to your SNMP agent

 Table 14-2: Squid ACL Options

The first step in configuring Squid security is to create ACLs. These are lists of hosts and domains for which you want to set up controls. You define ACLs using the acl command, creating a label for the systems on which you are setting controls. You then use commands such as http_access to define these controls. You can define a system, or a group of systems, by use of several acl options, such as the source IP address, the domain name, or even the time and date. For example, the src option is used to define a system or group of systems with a certain source address. To define a mylan acl entry for systems in a local network with the addresses 192.168.0.0 through 192.168.0.255, use the following ACL definition:

acl mylan src 192.168.0.0/255.255.255.0

Once it is defined, you can use an ACL definition in a Squid option to specify a control you want to place on those systems. For example, to allow access by the mylan group of local systems to the web through the proxy, use an http_access option with the allow action specifying mylan as the acl definition to use, as shown here:

http_access allow mylan

The default squid.conf file provides entries for controlling access to your local net and server ports.  Local net entries are listed for different local addresses (see Chapter 31). Both IPv4 and IPv6 versions are included.

acl localnet src 192.168.0.0.0/12  # RFC 1918 possible internal network
acl localnet src fc00:/7           # RFC 4193 local private network range

Access is supported on the SSL port, 443, and server ports such as 80 for the Web server and 21 for the FTP server are designated as safe.

acl SSL_ports  port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp

A default http_access entry is provided in the squid.conf file.  Access to outside users is denied, whereas access by hosts on the local network and the local host (Squid server host) is allowed.  A recommended minimum configuration restricts access to manager operations to the localhost and allows access from the localhost. Access is also denied on ports not deemed safe or without SSL security. The http_access entries already defined in the squid.conf file are shown here.

http_access allow manager localhost
http_access deny manager

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

http_access allow localnet
http_access allow localhost

http_access deny all

By defining ACLs and using them in Squid options, you can tailor your website with the kind of security you want. You should add your own ACLs after the comment label located near the middle of the file after the http_access entries for safe ports and before the http_access entries for the localnet and local host.

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FORM YOUR CLIENTS
#

The following example allows access to the web through the proxy by only the mylan group of local systems, denying access to all others. Two acl entries are set up: one for the local system and one for all others; http_access options first allow access to the local system and then deny access to all others.

acl mylan src 192.168.0.0/255.255.255.0
acl all src all
http_access allow mylan
http_access deny all

An entry for the mylan sample network, are shown here.

acl mylan src 192.168.0.0/255.255.255.0

The order of the http_access options is important. Squid starts from the first and works its way down, stopping at the first http_access option with an ACL entry that matches. In the preceding example, local systems that match the first http_access command are allowed, whereas others fall through to the second http_access command and are denied.

For systems using the proxy, you can also control what sites they can access. For a destination address, you create an acl entry with the dst qualifier. The dst qualifier takes as its argument the site address. Then you can create an http_access option to control access to that address. The following example denies access by anyone using the proxy to the destination site rabbit.mytrek.com. If you have a local network accessing the web through the proxy, you can use such commands to restrict access to certain sites.

acl myrabbit dst rabbit.mytrek.com
http_access deny myrabbit

The http_access entries already defined in the squid.conf file, along with an entry for the mylan network, are shown here. Access to outside users is denied, whereas access by hosts on the local network and the local host (Squid server host) is allowed.

http_access allow localhost
http_access allow mylan
http_access deny all

Proxy Caches

Squid primarily uses the Internet Cache Protocol (ICP) to communicate with other web caches. It also provides support for the more experimental Hypertext Cache Protocol (HTCP) and the Cache Array Routing Protocol (CARP).

Using the ICP protocols, your Squid cache can connect to other Squid caches or other cache servers, such as Microsoft proxy server, Netscape proxy server, and Novell BorderManager. This way, if your network’s Squid cache does not have a copy of a requested web page, it can contact another cache to see if it is there instead of accessing the original site. You can configure Squid to connect to other Squid caches by connecting it to a cache hierarchy. Squid supports a hierarchy of caches denoted by the terms child, sibling, and parent. Sibling and child caches are accessible on the same level and are automatically queried whenever a request cannot be located in your own Squid’s cache. If these queries fail, a parent cache is queried, which then searches its own child and sibling caches or its own parent cache, if needed, and so on.

You can set up a cache hierarchy to connect to the main NLANR server by registering your cache using the following entries in your squid.conf file:

cache_announce 24
announce_to sd.cache.nlanr.net:3131

Use cache_peer to set up parent, sibling, and child connections to other caches. This option has five fields. The first two consist of the hostname or IP address of the queried cache and the cache type (parent, child, or sibling). The third and fourth are the HTTP and the ICP ports of that cache, usually 3128 and 3130. The last is used for cache_peer options such as proxy-only to not save fetched objects locally, no-query for those caches that do not support ICP, and weight, which assigns priority to a parent cache. The following example sets up a connection to a parent cache:

cache_peer sd.cache.nlanr.net parent 3128 3130

Squid provides several options for configuring cache memory. The cache_mem option sets the memory allocated primarily for objects currently in use (objects in transit). If available, the space can also be used for frequently accessed objects (hot objects) and failed requests (negative-cache objects). The default is 8MB. The following example sets it to 256MB:

cache_mem 256 MB

To specify cache disk storage you can use the cache_dir option.  A default option is set up already, though commented out.   It takes as its arguments the amount of storage to use in megabytes, the number of first level subdirectories, and the number of second level directories.  The default settings are 100 MB with 16 first level directories and 256 second level directories.

cache_dir ufs /var/spool/squid  100  16  256

The minimum configuration also sets refresh_pattern options to control the freshness of objects that have no designated expiration time. There are entries for ftp and cgi-bin. The option sets the minimum and maximum times in minutes, along with the percentage of the object's age for which it is considered fresh.

refresh_pattern ^ftp:   1440    20%    100080

You can use the cache manager (cachemgr.cgi) to manage the cache and view statistics on the cache manager as it runs. To run the cache manager, use your browser to execute the cachemgr.cgi script (this script should be placed in your web server’s cgi-bin directory). Hosts allowed to use the cachemgr.cgi script are listed in the /etc/squid/cachemgr.conf file.  It contains a default entry for localhost.

Logs

Squid keeps several logs detailing access, cache performance, and error messages.

access.log holds requests sent to your proxy.

cache.log holds Squid server messages such as errors and startup messages.

store.log holds information about the Squid cache such as objects added or removed.

15. Domain Name System: BIND 9

The Domain Name System (DNS) is an Internet service that locates and translates domain names into their corresponding Internet Protocol (IP) addresses. All computers connected to the Internet are addressed using an IP address. As a normal user on a network might have to access many different hosts, keeping track of the IP addresses needed quickly became a problem. It was much easier to label hosts with names and use the names to access them. Names were associated with IP addresses. When a user used a name to access a host, the corresponding IP address was looked up first and then used to provide access.

With the changeover from IPv4 to IPv6 address, DNS servers will have some configuration differences. Both are covered here, though some topics will use IPv4 addressing for better clarity, as they are easier to represent.

DNS Address Translations

The process of translating IP addresses into associated names is fairly straightforward. Small networks can be set up easily, with just the basic configuration. The task becomes much more complex when you deal with larger networks and with the Internet. The sheer size of the task can make DNS configuration a complex operation.

 Fully Qualified Domain Names

IP addresses were associated with corresponding names, called fully qualified domain names. A fully qualified domain name is composed of three or more segments. The first segment is the name that identifies the host, and the remaining segments are for the network in which the host is located. The network segments of a fully qualified domain name are usually referred to simply as the domain name, while the host part is referred to as the hostname (though this is also used to refer to the complete fully qualified domain name). In effect, subnets are referred to as domains. The fully qualified domain name www.linux.org could have an IPv4 address 198.182.196.56, where 198.182.196 is the network address and 56 is the host ID. Computers can be accessed only with an IP address, so a fully qualified domain name must first be translated into its corresponding IP address to be of any use. The parts of the IP address that make up the domain name and the hosts can vary.

IPv4 Addressing

The IP address may be implemented in either the newer IPv6 (Internet Protocol Version 6) format or the older and more common IPv4 (Internet Protocol Version 4) format. Since the IPv4 addressing is much easier to read, that format will be used in these examples. In the older IPv4 format, the IP address consists of a number composed of four segments separated by periods. Depending on the type of network, several of the first segments are used for the network address and one or more of the last segments are used for the host address. In a standard class C network used in smaller networks, the first three segments are the computer’s network address and the last segment is the computer’s host ID (as used in these examples). For example, in the address 192.168.0.2, 192.168.0 is the network address and 2 is the computer’s host ID within that network. Together, they make up an IP address by which the computer can be addressed from anywhere on the Internet. IP addresses, though, are difficult to remember and easy to get wrong.

IPv6 Addressing

IPv6 addressing uses a very different approach designed to provide more flexibility and support for very large address spaces. There are three different types of IPv6 addresses, unicast, multicast, and anycast, of which unicast is the most commonly used. A unicast address is directed to a particular interface. There are several kinds of unicast addresses, depending on how the address is used. For example, you can have a global unicast address for access through the Internet or a site-level unicast address for private networks.

Though consisting of 128 bits in eight segments (16 bits, 2 bytes, per segment), an IPv6 address is made up of several fields that conform roughly to the segments and capabilities of an IPv4 address, networking information, subnet information, and the interface identifier (host ID). The network information includes a format prefix indicating the type of network connection. In addition, a subnet identifier can be used to specify a local subnet. The network information takes up the first several segments; the remainder is used for the interface ID. The interface ID is a 64-bit (four-segment) Extended Unique Identifier (EUI-64) generated from a network device's Media Access Control (MAC) address. IP addresses are written in hexadecimal numbers, making them difficult to use. Each segment is separated from the next by a colon, and a set of consecutive segments with zero values like the reserved segment can be left empty.

Manual Translations: /etc/hosts

Any computer on the Internet can maintain a file that manually associates IP addresses with domain names. On Linux and UNIX systems, this file is called the /etc/hosts file. Here, you can enter the IP addresses and domain names of computers you commonly access. Using this method, however, each computer needs a complete listing of all other computers on the Internet, and that listing must be updated constantly. Early on, this became clearly impractical for the Internet, though it is still feasible for small, isolated networks as well as simple home networks.

 DNS Servers

The Domain Name System has been implemented to deal with the task of translating the domain name of any computer on the Internet to its IP address. The task is carried out by interconnecting servers that manage the Domain Name System (also referred to as DNS servers or name servers). These DNS servers keep lists of fully qualified domain names and their IP addresses, matching one up with the other. This service that they provide to a network is referred to as the Domain Name System. The Internet is composed of many connected subnets called domains, each with its own Domain Name System (DNS) servers that keep track of all the fully qualified domain names and IP addresses for all the computers on its network. DNS servers are hierarchically linked to root servers, which, in turn, connect to other root servers and the DNS servers on their subnets throughout the Internet. The section of a network for which a given DNS server is responsible is called a zone. Although a zone may correspond to a domain, many zones may, in fact, be within a domain, each with its own name server. This is true for large domains where too many systems exist for one name server to manage.

 DNS Operation

When a user enters a fully qualified domain name to access a remote host, a resolver program queries the local network’s DNS server requesting the corresponding IP address for that remote host. With the IP address, the user can then access the remote host. In Figure 15-1, the user at rabbit.mytrek.com wants to connect to the remote host lizard.mytrek.com. rabbit.mytrek.com first sends a request to the network’s DNS server—in this case, turtle.mytrek.com—to look up the name lizard.mytrek.com and find its IP address. turtle.mytrek.com then returns the IP address for lizard.mytrek.com, 192.168.0.3, to the requesting host, rabbit.mytrek.com. With the IP address, the user at rabbit.mytrek.com can then connect to lizard.mytrek.com.

Figure 15-1: DNS server operation

DNS Clients: Resolvers

The names of the DNS servers that service a host’s network are kept in the host’s /etc/resolv.conf file. When setting up an Internet connection, the name servers provided by your Internet service provider (ISP) were placed in this file. These name servers resolve any fully qualified domain names that you use when you access different Internet sites. For example, when you enter a Web site name in your browser, the name is looked up by the name servers and the name’s associated IP address is then used to access the site.

/etc/resolv.conf

search  mytrek.com   mytrain.com
nameserver  192.168.0.1
nameserver  192.168.0.3

 Local Area Network Addressing

If you are setting up a DNS server for a local area network (LAN) that is not connected to the Internet, you should use a special set of IP numbers reserved for such local networks (also known as private networks or intranets). This is especially true if you are implementing IP masquerading, where only a gateway machine has an Internet address, and the others make use of that one address to connect to the Internet. Though structurally the same, IPv4 and IPv6 use different addressing formats for local addresses. Many local and home networks still use the IPv4 format, and this is the format used in the following local addressing example.

Address

Networks

10.0.0.0

Class A network

172.16.0.0–172.31.255.255

Class B network

192.168.0.0

Class C network

127.0.0.0

Loopback network (for system self-communication)

 Table 15-1: Non-Internet Private Network IP Addresses

IPv4 Private Networks

IPv4 provides a range of private addresses for the three classes supported by IPv4. As you have seen, class C IPv4 network numbers have the special network number 192.168. Numbers are also reserved for class A and class B non-Internet local networks. Table 15-1 lists these addresses. The possible addresses available span from 0 to 255 in the host segment of the address. For example, class B network addresses range from 172.16.0.0 to 172.16.255.255, giving you a total of 65,534 possible hosts. The class C network ranges from 192.168.0.0 to 192.168.255.255, giving you 254 possible subnetworks, each with 254 possible hosts. The number 127.0.0.0 is reserved for a system’s loopback interface, which allows it to communicate with itself, as it enables users on the same system to send messages to each other.

These numbers were originally designed for class-based addressing. However, they can just as easily be used for Classless Interdomain Routing (CIDR) addressing, where you can create subnetworks with a smaller number of hosts. For example, the 254 hosts addressed in a class C network could be split into two subnetworks, each with 125 hosts.

IPv6 Private Networks

IPv6 supports private networks with unique-local addresses that provide the same functionality of IPv4 private addresses. The unique-local addresses have no public routing information. They cannot access the Internet. They are restricted to the site they are used on. The unique-local addresses use only three fields: a format prefix, subnet identifier, and interface identifier. A site-level address has the format prefix fc00. If you have no subnets, it will be set to 0. This will give you a network prefix of fc00:0:0:0. You can drop the set of empty zeros to give you fc00::. The interface ID field will hold the interface identification information, similar to the host ID information in IPv4.

fc00::           IPv6 unique-local prefix

The loopback device will have the special address of ::1, also known as localhost.

::1             IPv6 loopback network

Rather than using a special set of reserved addresses as IPv4 does, with IPv6 you only use the unique-local prefix, fc00, and the special loopback address, ::1.

Local Network Address Example Using IPv4

If you are setting up a LAN, such as a small business or home network, you are free to use class C IPv4 network (254 hosts or less), that have the special network number 192.168, as used in these examples. These are numbers for your local machines. You can set up a private network, such as an intranet, using network cards such as Ethernet cards and Ethernet hubs, and then configure your machines with IP addresses starting from 192.168.0.1. The host segment can range from 1 to 254, where 255 is used for the broadcast address. If you have three machines on your home network, you can give them the addresses 192.168.0.1, 192.168.0.2, and 192.168.0.3. You can then set up domain name system services for your network by running a DNS server on one of the machines. This machine becomes your network’s DNS server. You can then give your machines fully qualified domain names and configure your DNS server to translate the names to their corresponding IP addresses. As shown in Figure 15-1, for example, you could give the machine 192.168.0.1 the name turtle.mytrek.com and the machine 192.168.0.2 the name rabbit.mytrek.com. You can also implement Internet services on your network such as FTP, Web, and mail services by setting up servers for them on your machines. You can then configure your DNS server to let users access those services using fully qualified domain names. For example, for the mytrek.com network, the Web server could be accessed using the name www.mytrek.com. Instead of a Domain Name System, you could have the /etc/hosts files on each machine contain the entire list of IP addresses and domain names for all the machines in your network. But for any changes, you would have to update each machine’s /etc/hosts file.

BIND

The DNS server software currently in use on Linux systems is Berkeley Internet Name Domain (BIND). BIND was originally developed at the University of California, Berkeley, and is currently maintained and supported by the Internet Software Consortium (ISC). You can obtain BIND information and current software releases from its Web site at https://www.isc.org/. Web page documentation and manuals are included with the software package. At the site, you can also access the BIND Administration Manual for detailed configuration information. RPM packages are available at distribution FTP sites. The BIND directory in /usr/share/doc contains extensive documentation, including Web page manuals and examples. The Linux HOW-TO for the Domain Name System, DNS-HOWTO, provides detailed examples.

The BIND 9 Administrator Reference Manual is located in the /usr/share/doc/BIND directory. Also, check the https://www.isc.org/ site for the latest version.

/usr/share/doc/bind/Bv9ARM.html

BIND 9

The BIND 9 DNS server software consists of a name server daemon, several sample configuration files, and resolver libraries. The version of BIND, beginning with the series number 8.x, implemented a new configuration file using a new syntax. Version 9.0 adds new security features and support for IPv6. Older versions, which begin with the number 4.x, use a different configuration file with an older syntax. The newest version 10, which uses a radically new approach to DNS server management.  Most systems may still use the older 9.x version of BIND.

Tool

Description

dig domain

Domain Information Groper, tool to obtain information on a DNS server.

host hostname

Simple lookup of hosts

nslookup domain

Tool to query DNS servers for information about domains and hosts

named-checkconf

BIND tool to check the syntax of your DNS configuration file, /etc/named.conf

named-checkzone

BIND tool to check the syntax of your DNS zone files

nslint

Tool to check the syntax of your DNS configuration and zone files

rndc command

Remote Name Daemon Controller, an administrative tool for managing a DNS server (version 9.x)

ndc

Name Daemon Controller (version 8.x)

system-config-bind

Fedora Bind DNS server configuration tool

named-rrchecker

BIND tool to check the syntax of your DNS resource records

arpaname

Tool to translate IP address to an IN-ADDR.ARPA address used for reverse resolutions

bind9

Start, stop, and restart the named server with the bind9.service file

 Table 15-2: BIND 9 Diagnostic and Administrative Tools

The name of the BIND name server daemon is named. To operate your machine as a name server, simply run the named daemon with the appropriate configuration. The named daemon listens for resolution requests and provides the correct IP address for the requested hostname. You can use the Remote Name Daemon Controller utility, rndc, provided with BIND to start, stop, restart, and check the status of the server as you test its configuration. rndc with the stop command stops named and, with the start command, starts it again, reading your named.conf file. rndc with the help command provides a list of all rndc commands. Configuration is set in the /etc/rndc.conf file. Once your name server is running, you can test it using the dig or nslookup utility, which queries a name server, providing information about hosts and domains. If you start dig with no arguments, it enters an interactive mode where you can issue different dig commands to refine your queries.

To check the syntax of your DNS server configuration and zone files, BIND provides the named-checkconfig and named-checkzone tools: named-checkconfig will check the syntax of DNS configuration file, named.conf, and named-checkzone will check a zone file's syntax. Other syntax checking tools are also available, such as nslint, which operates like the programming tool lint. Table 15-2 lists several DNS administrative tools.

On most distributions, named runs as a stand-alone daemon, starting up when the system boots and constantly running. If you don’t want named to start up automatically, you can use  chkconfig to change its status.

Stopping and Starting the BIND 9 server

The named daemon is managed by systemd using the named.service unit file. It is started for the multi-user.target (runlevels 2, 3, 4, and 5) (WantedBy).  Runtime configuration is read from /etc/sysconfig/named (EnvironmentFile). Though the /usr/sbin/named command starts the server (ExecStart), the rndc command is used to restart or stop the server (ExecReload and ExecStop).  The bind service requires that the special target nss-lookup.target be activated (Wants).  Before the bind server starts, configuration information is read from named.conf using named-chkconf (ExecStartPre). 

named.service

[Unit]
Description=Berkeley Internet Name Domain (DNS)
Wants=nss-lookup.target
Wants=named-setup-rndc.service
Before=nss-lookup.target
After=named-setup-rndc.service
After=network.target

[Service]
Type=forking
EnvironmentFile=NAMEDCONF=/etc/named.conf
EnvironmentFile=-/etc/sysconfig/named
Environment=KRB5_KTNAME=/etc/named.keytab
PIDFile=/run/named/named.pid
ExecStartPre=/bin/bash -c 'if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z /etc/named.conf; else echo "Checking of zone files is disabled"; fi'
ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS
ExecReload=/bin/sh -c '/usr/sbin/rndc reload > /dev/null 2>&1 || /bin/kill -HUP $MAINPID'
ExecStop=/bin/sh -c '/usr/sbin/rndc stop > /dev/null 2>&1 || /bin/kill -TERM $MAINPID'
PrivateTmp=true

[Install]
WantedBy=multi-user.target

You can use the systemctl command to manually stop, start, and restart the server, as well as enable for disable it. 

sudo systemctl enable named
sudo systemctl start named

Note: system-config-bind is an older desktop application for configuring the BIND DNS server. Though deprecated on Red Hat and Centos, it is still available on the Fedora repository, though it is no longer supported. It may not work well on Fedora 28.

Domain Name System Configuration

You configure a DNS server using a configuration file, several zone files, and a cache file. The part of a network for which the name server is responsible is called a zone. A zone is not the same as a domain because in a large domain you could have several zones, each with its own name server. You could also have one name server service several zones. In this case, each zone has its own zone file.

 DNS Zones

The zone files hold resource records that provide hostname and IP address associations for computers on the network for which the DNS server is responsible. Zone files exist for the server’s network and the local machine. Zone entries are defined in the named.conf file. Here, you place zone entries for your master, slave, and forward DNS servers. The most commonly used zone types are described here:

Master zone This is the primary zone file for the network supported by the DNS server. It holds the mappings from domain names to IP addresses for all the hosts on that network.

Slave zone These are references to other DNS servers for your network. Your network can have a master DNS server and several slave DNS servers to help carry the workload. A slave DNS server automatically copies its configuration files, including all zone files, from the master DNS server. Any changes to the master configuration files trigger an automatic download of these files to the slave servers. In effect, you only have to manage the configuration files for the master DNS server, as they are automatically copied to the slave servers.

Forward zone The forward zone lists name servers outside your network that should be searched if your network’s name server fails to resolve an address.

in-addr.arpa zone DNS can also provide reverse resolutions, where an IP address is used to determine the associated domain name address. Such lookups are provided by in-addr.arpa zone files. Each master zone file usually has a corresponding in-addr.arpa zone file to provide reverse resolution for that zone. For each master zone entry, a corresponding reverse mapping zone entry named in-addr.arpa also exists, as well as one for the localhost. This entry performs reverse mapping from an IP address to its domain name. The name of the zone entry uses the domain IP address, which is the IP address with segments listed starting from the host, instead of the network. So for the IP address 192.168.0.4, where 4 is the host address, the corresponding domain IP address is 4.0.168.192, listing the segments in reverse order. The reverse mapping for the localhost is 1.0.0.127.

IP6.ARPA zone This is the IPv6 equivalent of the in-addr.arpa zone, providing reverse resolution for that zone. The IP6.ARPA zone uses bit labels provide a bit-level format that is easier to write, requiring no reverse calculation on the part of the DNS administrator.

IP6.INT zone This is the older form of the IPv6 IP6.ARPA zone, which is the equivalent of the IPv4 in-addr.arpa zone, providing reverse resolution for a zone. IP6.INT is meant to be used with the AAAA IPv6 address records. IP6.INT uses a nibble format to specify a reverse zone. In this format, a hexadecimal IPv6 address is segmented into each of its 32 hexadecimal numbers and listed in reverse order, each segment separated by a period.

Hint zone A hint zone specifies the root name servers and is denoted by a period (.). A DNS server is normally connected to a larger network, such as the Internet, which has its own DNS servers. DNS servers are connected this way hierarchically, with each server having its root servers to which it can send resolution queries. The root servers are designated in the hint zone.

 DNS Servers Types

There are several kinds of DNS servers, each designed to perform a different type of task under the Domain Name System. The basic kind of DNS server is the master server. Each network must have at least one master server that is responsible for resolving names on the network. Large networks may need several DNS servers. Some of these can be slave servers that can be updated directly from a master server. Others may be alternative master servers that hosts in a network can use. Both are commonly referred to as secondary servers. For DNS requests a DNS server cannot resolve, the request can be forwarded to specific DNS servers outside the network, such as on the Internet. DNS servers in a network can be set up to perform this task and are referred to as forwarder servers. To help bear the workload, local DNS servers can be set up within a network that operate as caching servers. Such a server merely collects DNS lookups from previous requests it sent to the main DNS server. Any repeated requests can then be answered by the caching server.

A server that can answer DNS queries for a given zone with authority is known as an authoritative server. An authoritative server holds the DNS configuration records for hosts in a zone that will associate each host’s DNS name with an IP address. For example, a master server is an authoritative server. So are slave and stealth servers (see the list that follows). A caching server is not authoritative. It only holds whatever associations it picked up from other servers and cannot guarantee that the associations are valid. A new feature introduced with 9.10 for Authoritative servers is Response Rate Limiting (RRL), which controls DNS response packets to avoid DNS amplification attacks (a type of Distributed Denial of Service attack, DDOS).

Master server This is the primary DNS server for a zone.

Slave server A DNS server that receives zone information from the master server.

Forwarder server A server that forwards unresolved DNS requests to outside DNS servers. Can be used to keep other servers on a local network hidden from the Internet.

Caching only server Caches DNS information it receives from DNS servers and uses it to resolve local requests.

Stealth server A DNS server for a zone not listed as a name server by the master DNS server.

 Location of Bind 9 Server Files and BIND chroot

The BIND package installs the BIND server files in the /etc and /var/bind directories.  The BIND named.conf file is located in the /etc directory (/etc/named.conf), and the zone files are located in the /var/bind directory. 

/etc/named.conf           BIND configuration file
/var/named/               BIND zone files

Alternatively, you can choose to implement a more secure server by having the configuration files placed in a chroot jail. Install the bind-chroot package. Both the configuration and zone files used by BIND are then placed in a special subdirectory called chroot located within the /var/named directory, /var/named/chroot. The chroot directory sets up a chroot jail, creating a virtual root directory for any users of the DNS service. This prevents access by DNS users to any other part of the system. When the BIND server starts up, the chroot command is run on the named service making /var/named/chroot the root directory for any users of the DNS service. Check the Chroot-BIND HOWTO at the Linux Documentation site for more information (https://www.tldp.org).

Within the /var/named/chroot directory are subdirectories that hold the BIND files on your system. These include var, etc, and dev. The var subdirectory has a named subdirectory within which are the zone files used by the BIND DNS server. Links to these files are located in the /var/named directory. The named.conf configuration file is located in the /var/named/chroot/etc directory.

/var/named/chroot/etc/named.conf           BIND configuration file
/var/named/chroot/var/named                BIND zone files

named.conf (BIND 9)

The configuration file for the named daemon is named.conf, located in the /etc directory (/etc/named.conf). It uses a flexible syntax similar to C programs. The format enables easy configuration of selected zones, enabling features such as access control lists and categorized logging. The named.conf file consists of BIND configuration statements with attached blocks within which specific options are listed. A configuration statement is followed by arguments and a block that is delimited with braces. Within the block are lines of option and feature entries. Each entry is terminated with a semicolon. Comments can use the C, C++, or Shell/Perl syntax: enclosing /* */, preceding //, or preceding #. The following example shows a zone statement followed by the zone name and a block of options that begin with an opening brace ({). Each option entry ends with a semicolon. The entire block ends with a closing brace, also followed by a semicolon. The format for a named.conf entry is shown here, along with the different kinds of comments allowed. Tables 15-3, 15-4, and 15-5 list several commonly used statements and options.

// comments
/* comments */
# comments

statements {
options and features; //comments
};

The following example shows the zone statement for a simple caching server entry:

// a caching only nameserver config
//
zone "." IN {
       type hint;
       file "named.ca";
       };

Once you have created your configuration file, you should check its syntax with the named-checkconfig tool. Enter the command on a shell command line. If you do not specify a configuration file, it will default to /etc/named.conf.

named-checkconfig

The zone Statement

The zone statement is used to specify the domains the name server will service. To create a zone statement, you enter the keyword zone, followed by the name of the domain placed within double quotes. Do not place a period at the end of the domain name. In the following example, a period is within the domain name, but not at the end, “mytrek.com”; this differs from the zone file, which requires a period at the end of a complete domain name.

Type

Description

master

Primary DNS zone

slave

Slave DNS server; controlled by a master DNS server

hint

Set of root DNS Internet servers

forward

Forwards any queries in it to other servers

stub

Like a slave zone, but holds only names of DNS servers

 Table 15-3: DNS BIND Zone Types

After the zone name, you can specify the class IN, which stands for Internet. You can also leave it out, in which case IN is assumed (there are only a few other esoteric classes that are rarely used). Within the zone block, you can place several options (see Table 15-3). Two essential options are type and file. The type option is used to specify the zone’s type. The file option is used to specify the name of the zone file to be used for this zone. You can choose from several types of zones: master, slave, stub, forward, and hint. Master specifies that the zone holds master information and is authorized to act on it. A master server was called a primary server in the older 4.x BIND configuration. Slave indicates that the zone needs to update its data periodically from a specified master name server. You use this entry if your name server is operating as a secondary server for another primary (master) DNS server. A stub zone copies only other name server entries, instead of the entire zone. A forward zone directs all queries to name servers specified in a forwarders statement. A hint zone specifies the set of root name servers used by all Internet DNS servers. You can also specify several options that can override any global options set with the options statement. Table 15-3 lists the BIND zone types. The following example shows a simple zone statement for the mytrek.com domain. Its class is Internet (in), and its type is master. The name of its zone file is usually the same as the zone name with the .db extension, in this case, “mytrek.com.db.”

zone "mytrek.com" in {
       type master;
       file "mytrek.com.db";
       };

Configuration Statements

Other statements, such as acl, server, options, and logging, enable you to configure different features for your name server (see Table 15-4). The server statement defines the characteristics to be associated with a remote name server, such as the transfer method and key ID for transaction security. The control statement defines special control channels. The key statement defines a key ID to be used in a server statement that associates an authentication method with a particular name server (see “DNSSEC” later in this chapter). The logging statement is used to configure logging options for the name server, such as the maximum size of the log file and a severity level for messages.

Statement

Description

/* comment */

BIND comment in C syntax.

// comment

BIND comment in C++ syntax.

# comment

BIND comment in Unix shell and Perl syntax.

acl

Defines a named IP address matching list.

include

Includes a file, interpreting it as part of the named.conf file.

key

Specifies key information for use in authentication and authorization.

logging

Specifies what the server logs and where the log messages are sent.

options

Global server configuration options and defaults for other statements.

controls

Declares control channels to be used by the ndc utility.

server

Sets certain configuration options for the specified server basis.

sortlists

Gives preference to specified networks according to a queries source.

trusted-keys

Defines DNSSEC keys preconfigured into the server and implicitly trusted.

zone

Defines a zone.

view

Defines a view.

 Table 15-4: BIND Configuration Statements

Option

Description

type

Specifies a zone type.

file

Specifies the zone file for the zone.

directory

Specifies a directory for zone files.

forwarders

Lists hosts for DNS servers where requests are to be forwarded.

masters

Lists hosts for DNS master servers for a slave server.

notify

Allows master servers to notify their slave servers when the master zone data changes and updates are needed.

allow-transfer

Specifies which hosts are allowed to receive zone transfers.

allow-query

Specifies hosts that are allowed to make queries.

allow-recursion

Specifies hosts that are allowed to perform recursive queries on the server.

 Table 15-5: Zone Options

Table 15-5 lists the BIND statements. The sortlists statement lets you specify preferences to be used when a query returns multiple responses. For example, you could give preference to your localhost network or to a private local network such a 192.168.0.0.

The options Statement

The options statement defines global options and can be used only once in the configuration file. An extensive number of options cover such components as forwarding, name checking, directory path names, access control, and zone transfers, among others (see Table 15-6). A complete listing can be found in the BIND documentation.

Option

Description

sortlist

Gives preference to specified networks according to a queries source.

directory

Specifies a directory for zone files.

forwarders

Lists hosts for DNS servers where requests are to be forwarded.

allow-transfer

Specifies which hosts are allowed to receive zone transfers.

allow-query

Specifies hosts that are allowed to make queries.

allow-recursion

Specifies hosts that are allowed to perform recursive queries on the server.

notify

Allows master servers to notify their slave servers when the master zone data changes and updates are needed.

blackhole

Option to eliminate denial response by allow-query.

recursion

Allow the DNS server to query other DNS servers it does not control.

 Table 15-6: Bind Options for the options Statement

The directory Option

A critically important option found in most configuration files is the directory option, which holds the location of the name server’s zone and cache files on your system. The following example is taken from the /etc/named.conf file. This example specifies the zone files are located in the /var/named directory. In this directory, you can find your zone files, including those used for your local system. The example uses IPv4 addresses.

options {
        directory "/var/named";
        forwarders { 192.168.0.34;
                    192.168.0.47;
                   };
       };

The forwarders Option

Another commonly used global option is the forwarders option. With the forwarders option, you can list several DNS servers to which queries can be forwarded if they cannot be resolved by the local DNS server. This is helpful for local networks that may need to use a DNS server connected to the Internet. The forwarders option can also be placed in forward zone entries.

The notify Option

With the notify option turned on, the master zone DNS servers send messages to any slave DNS servers whenever their configuration has changed. The slave servers can then perform zone transfers in which they download the changed configuration files. Slave servers always use the DNS configuration files copied from their master DNS servers. The notify option takes one argument, yes or no, where yes is the default. With the no argument, you can have the master server not send out any messages to the slave servers, in effect preventing any zone transfers.

The IPv6 reverse mapping uses the IP6.ARPA domain in the reverse zone entries). IP6.ARPA uses bit labels providing bit-level specification for the address. This is simply the full hexadecimal address, including zeros, without intervening colons. You can also use the nibble format, separating each numeral with a period.

A simple named.conf Example

The following example is a simple named.conf file based on the example provided in the BIND documentation (see /usr/share/doc/bind*/sample/etc/named.conf for a more detailed example). This example shows samples of several of the configuration statements.

The file begins with comments using C++ syntax, //. The logging statement logs debug messages to the /var/named/data/named.run file. The named server is allowed to write to files in the data subdirectory. The options statement has a directory entry that sets the directory for the zone and cache files to /var/named. Here, you find links to your zone files, such as named.local and reverse mapping files, along with the cache file, named.ca. The first zone statement (.) defines a hint zone specifying the root name servers. The cache file listing these servers is named.ca. The second zone statement defines a zone for the mytrek.com domain. Its type is master, and its zone file is named mytrek.com.

The next zone is used for reverse IPv4 mapping of the previous zone. Its name is made up of a reverse listing of the mytrek.com domain’s IP address with the term in-addr.arpa appended. The domain address for mytrek.com is 192.168.0, so the reverse is 1.168.192. The in-addr.arpa domain is a special domain that supports gateway location and Internet address–to–host mapping.

The last statement will include the named.rfc1912.zones configuration file which defines zone statements for the localhost and its reverse lookup. These are the RFC 1912 zone definitions for the loopback interface (localhost, 1.0.0.127), the method used by the system to address itself and enable communication between local users on the system.

include "/etc/named.rfc1912.zones"

named.conf

//
// A simple BIND 9 configuration
//

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
                };
        };

options {
         directory "/var/named";
         };

zone "." IN {
          type hint;
          file "named.ca";
         };

zone "mytrek.com" {
             type master;
             file "mytrek.com.db";
             };
zone "1.168.192.in-addr.arpa" {
                             type master;
                             file "192.168.0.db";
                            };

zone "\[xFC00000000000000/64].IP6.ARPA" {
                             type master;
                             file "fec.ip6.arpa.db";
                            };

include "/etc/named.rfc1912.zones"

The view clause

The zone statements are arranged within view clauses, which determine how the DNS server responds to client requests. If no view clause is listed, then all the zone statements are assumed to be part of a default view, accessible by all clients.  If at least one view statement is listed, then all zone statements must be placed within view clauses.    

DNS views are configured with the view clause, which uses the match-clients option to specify client addresses that can access the view and the match-destinations option for addresses that can be accessed by clients. The match-recursive-only option allows recursive requests. Options defined within the view apply only to that view.

//
// A simple BIND 9 configuration
//

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
                };
        };

options {
         directory "/var/named";
         };

view "internal" {
    match-clients {192.168.0.0/32;};
    match-destinations {any};
    recursion yes;

    zone "." IN {
          type hint;
          file "named.ca";
         };

    zone "mytrek.com" {
             type master;
             file "mytrek-internal.com.db";
             };

    zone "1.168.192.in-addr.arpa" {
                             type master;
                             file "192.168.0.db";
                            };

    zone "\[xFC00000000000000/64].IP6.ARPA" {
                             type master;
                             file "fec.ip6.arpa.db";
                            };

include "/etc/named.rfc1912.zones"
}

The view clause begins with a view keyword followed by the name of the view, such as internal, external, or localhost-resolver. Then the match-clients and match-destinations options define the addresses that can access the view.  The named.conf.sample file shows how a named.conf file can be configured for internal, external, and local-resolver zones.

Views are normally set up for internal and external clients.  An internal view would allow clients on a local network access to the entire local network, including any servers used for external use such as a Web server for the Internet.  An external view would allow access by any client, local and otherwise, but restrict that access to the external servers such as Web and mail servers with Internet access.  The external view would prevent non-local clients from accessing the local network except for Internet servers running on that network.

The next example sets up an internal view for local clients, which restricts access by clients from the local network (192.168.0.0), though these clients can access any destination.  Recursion is allowed. The local clients have full use of the DNS zone.  The root zone definition has to be included for Internet access (zone "."). The zone definition for the mytrek.com zone loads a mytrek-internal.com.db file which contains the resource records for accessing the entire network.

The external view is usually designed to allow access of all clients, both internal and external. The following example sets up an external view for both clients. The match-clients option is set to any which matches on any client anywhere accessing the zone.  Recursion is turned off. The zone definition for the mytrek.com zone loads a mytrek-external.com.db file which contains the resource records for accessing the public servers only, such as the Web and mail servers.

view "external" {
    match-clients {any};
    recursion no;

    zone "." IN {
          type hint;
          file "named.ca";
         };

    zone "mytrek.com" {
             type master;
             file "mytrek-external.com.db";
             };
    }

Instead of using the same zone name, you can create new zones for your external zones.  In the following example, the myweb.com.db file will hold resource records just for the Web server.

view "external" {
    match-clients {any};
    recursion no;

    zone "." IN {
          type hint;
          file "named.ca";
         };

    zone "myweb.com" {
             type master;
             file "myweb.com.db";
             };
    }

The named.conf file with both external and internal views of the mytrek.com zone is shown here:

// A BIND 9 configuration with external and internal views

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic; };
        };

options {
         directory "/var/named";
         };

view "internal" {
    match-clients {192.168.0.0/32;};
    match-destinations {any};
    recursion yes;

    zone "." IN {
          type hint;
          file "named.ca";
         };

    zone "mytrek.com" {
             type master;
             file "mytrek-internal.com.db";
             };

    zone "1.168.192.in-addr.arpa" {
                             type master;
                             file "192.168.0.db";
                            };

    zone "\[xFC00000000000000/64].IP6.ARPA" {
                             type master;
                             file "fec.ip6.arpa.db";
                            };

    include "/etc/named.rfc1912.zones"
    }

view "external" {
    match-clients {any};
    recursion no;

    zone "." IN {
          type hint;
          file "named.ca";
         };

    zone "mytrek.com" {
             type master;
             file "mytrek-external.com.db";
             };
    }

BIND 9 Caching-Only Server

When BIND is initially installed, it creates a default configuration for what is known as a caching-only server. A caching-only server copies queries made by users and saves them in a cache, for use later if the queries are repeated. This can save DNS lookup response times. The cache is held in memory and lasts only as long as named runs.

named.conf as a caching-only server

//
// named.conf
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

options {
     listen-on port 53 { 127.0.0.1; };
     listen-on-v6 port 53 { ::1; };
     directory      "/var/named";
     dump-file      "/var/named/data/cache_dump.db";
     statistics-file "/var/named/data/named_stats.txt";
     memstatistics-file "/var/named/data/named_mem_stats.txt";
     secroots-file     "/var/named/data/named.secroots";
     recursing-file    "/var/named/data/named.recursing";    
     allow-query     { localhost; };

     recursion yes;

     dnssec-enable yes;
     dnssec-validation yes;

     managed-keys-directory "/var/named/dynamic";
     pid-file "/run/named/named.pid";
     session-keyfile "/run/named/session.key";

     include "etc/crypto-policies/back-ends/bind.config";
       };

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
                };
        };

zone "." IN {
     type hint;
     file "named.ca";
       };

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

The caching-only server configuration file is default named.conf file. This file contains basic options for managing the caching server. It includes the named.rfc1912.zones file (also in /etc).

The caching-only server is configured to use DNSsec security.  The dnssec options are enabled, validation set up, and key files referenced. The /etc/named.root.key file is read in which lists the DNSKEY for the root zone. See the section on DNSSEC later in this chapter.

Resource Records for Zone Files

Your name server holds domain name information about the hosts on your network in resource records placed in zone and reverse mapping files. Resource records are used to associate IP addresses with fully qualified domain names. You need a record for every computer in the zone that the name server services. A record takes up one line, though you can use parentheses to use several lines for a record, as is usually the case with SOA records. A resource record uses the Standard Resource Record Format as shown here:

name [<ttl>] [<class>] <type> <rdata> [<comment>]

Here, name is the name for this record. It can be a domain name or a hostname (fully qualified domain name). If you specify only the hostname, the default domain is appended. If no name entry exists, the last specific name is used. If the @ symbol is used, the name server’s domain name is used. ttl (time to live) is an optional entry that specifies how long the record is to be cached ($TTL directive sets default). class is the class of the record. The class used in most resource record entries is IN, for Internet. By default, it is the same as that specified for the domain in the named.conf file. type is the type of the record. rdata is the resource record data. The following is an example of a resource record entry. The name is rabbit.mytrek.com, the class is Internet (IN), the type is a host address record (A), and the data is the IP address 192.168.0.2.

rabbit.mytrek.com.    IN   A   192.168.0.2

 Resource Record Types

Different types of resource records exist for different kinds of hosts and name server operations (see Table 15-7 for a listing of resource record types).

A, NS, MX, PTR, and CNAME are the types commonly used. A is used for host address records that match domain names with IP addresses. NS is used to reference a name server. MX specifies the host address of the mail server that services this zone. The name server has mail messages sent to that host. The PTR type is used for records that point to other resource records and is used for reverse mapping. CNAME is used to identify an alias for a host on your system.

$TTL 86400

Time To Live Directive and Field: $TTL

All zone files begin with a Time To Live directive, which specifies the time that a client should keep the provided DNS information before refreshing the information again from the DNS server. Realistically this should be at least a day, though if changes in the server are scheduled sooner, you can temporarily shorten the time, later restoring it. Each record, in fact, has a Time To Live value that can be explicitly indicated with the TTL field. This is the second field in a resource record. If no TTL field is specified in the record, then the default as defined by the $TLL directive can be used. The $TTL directive is placed at the beginning of each zone file. By default, it will list the time in seconds, usually 86400, 24 hours.

Type

Description

A

An IPv4 host address, maps hostname to IPv4 address

AAAA

An IPv6 host address

A6

A chained  IPv6 address

NS

Authoritative name server for this zone

CNAME

Canonical name, used to define an alias for a hostname

SOA

Start of Authority, starts DNS entries in zone file, specifies name server for domain

WKS

Well-known service description

PTR

Pointer record, for performing reverse domain name lookups

RP

Text string that contains contact information about a host

HINFO

Host information

MINFO

Mailbox or mail list information

MX

Mail exchanger, informs remote site of your zone’s mail server

TXT

Text strings, usually information about a host

KEY

Domain private key

SIG

Resource record signature

NXT

Next resource record

 Table 15-7: Domain Name System Resource Record Types

You can also specify the time in days (d), hours (h), or minutes (m), as in

$TTL 2d3h

When used as a field, the TTL will be a time specified as the second field. In the following example, the turtle resource record can be cached for three days. This will override the default time in the TTL time directive:

turtle     3d      IN    A      192.168.0.1

 Start of Authority: SOA

A zone or reverse mapping file always begins with a special resource record called the Start of Authority (SOA) record. This record specifies that all the following records are authoritative for this domain. It also holds information about the name server’s domain, which is to be given to other name servers. An SOA record has the same format as other resource records, though its data segment is arranged differently. The format for an SOA record follows:

name {ttl} class SOA Origin Person-in-charge (
                                Serial number
                                Refresh
                                Retry
                                Expire
                                Minimum )

Each zone has its own SOA record. The SOA begins with the zone name specified in the named.conf zone entry. This is usually a domain name. An @ symbol is usually used for the name and acts like a macro expanding to the domain name. The class is usually the Internet class, IN. SOA is the type. Origin is the machine that is the origin of the records, usually the machine running your name server daemon. The person-in-charge is the e-mail address for the person managing the name server (use dots, not @, for the e-mail address, as this symbol is used for the domain name). Several configuration entries are placed in a block delimited with braces. The first is the serial number. You change the serial number when you add or change records, so that it is updated by other servers. The serial number can be any number, as long as it is incremented each time a change is made to any record in the zone. A common practice is to use the year-month-day-number for the serial number, where number is the number of changes in that day. For example, 1999120403 would be the year 1999, December 4, for the third change. Be sure to update it when making changes.

Refresh specifies the time interval for refreshing SOA information. Retry is the frequency for trying to contact an authoritative server. Expire is the length of time a secondary name server keeps information about a zone without updating it. Minimum is the length of time records in a zone live. The times are specified in the number of seconds.

The following example shows an SOA record. The machine running the name server is turtle.mytrek.com, and the e-mail address of the person responsible for the server is hostmaster.turtle.mytrek.com. Notice the periods at the ends of these names. For names with no periods, the domain name is appended. turtle would be the same as turtle.mytrek.com. When entering full hostnames, be sure to add the period so that the domain is not appended.

@ IN SOA turtle.mytrek.com. hostmaster.turtle.mytrek.com. (
                                    1997022700 ; Serial
                                    28800 ; Refresh
                                    14400 ; Retry
                                    3600000 ; Expire
                                    86400 ) ; Minimum

 Name Server: NS

The name server record specifies the name of the name server for this zone. These have a resource record type of NS. If you have more than one name server, list them in NS records. These records usually follow the SOA record. As they usually apply to the same domain as the SOA record, their name field is often left blank to inherit the server’s domain name specified by the @ symbol in the previous SOA record.

              IN   NS      turtle.mytrek.com.

You can, if you wish, enter the domain name explicitly as shown here:

mytrek.com.  IN   NS      turtle.mytrek.com.

 Address Record: A, A6, and AAAA

Resource records of type A are address records that associate a fully qualified domain name with an IP address. Often, only their hostname is specified. Any domain names without a terminating period automatically have the domain appended to them. Given the domain mytrek.com, the turtle name in the following example is expanded to turtle.mytrek.com:

rabbit.mytrek.com. IN    A      192.168.0.2
turtle             IN    A      192.168.0.1

BIND supports IPv6 addresses. IPv6 IP addresses have a very different format from that of the IPv4 addresses commonly used. Instead of the numerals arranged in four segments, IPv6 uses hexadecimal numbers arranged in seven segments. In the following example, turtle.mytrek.com is associated with a unique-local IPv6 address: fc00::. Recall that there are only three fields in a unique-local address: format prefix, subnet identifier, and interface identifier. The empty segments of the subnet identifier can be represented by an empty colon pair (::). The interface identifier follows, 8:800:200C:417A.

turtle.mytrek.com. IN    AAAA    FC00::8:800:200C:417A

IPv6 also supports the use of IPv4 addresses as an interface identifier, instead of the MAC-derived identifier. The network information part of the IPv6 address would use IPv6 notation, and the remaining interface (host) identifier would use the full IPv4 address. These are known as mixed addresses. In the next example, lizard.mytrek.com is given a mixed address using IPv6 network information and IPv4 interface information. The IPv6 network information is for an IPv6 unique-local address.

lizard.mytrek.com. IN      AAAA        fc00::192.168.0.3

The AAAA record is used in most networks for an IPv6 record. An AAAA record operates much like a standard A address record, requiring a full IPv6 address. An A6 record is an experimental version of the IPv6 record. It can be more flexible, in that it does not require a full address. Instead, you chain A6 records together, specifying just part of the address in each. For example, you could specify just an interface identifier for a host, letting the network information be provided by another IPv6 record (you can implement an A6 record with a full address, just like an AAAA record). In the next example, the first A6 record lists only the address for the interface identifier for the host divit. Following the address is the domain name, mytrek.com, whose address is to be used to complete divit's address, providing network information. The next A6 record provides the network address information for mytrek.com.

divit.mygolf.com. IN    A6   0:0:0:0:1234:5678:3466:af1f  mytrek.com.
mytrek.com.       IN    A6    3ffe:8050:201:1860::

 Mail Exchanger: MX

The Mail Exchanger record, MX, specifies the mail server that is used for this zone or for a particular host. The mail exchanger is the server to which mail for the host is sent. In the following example, the mail server is specified as turtle.mytrek.com. Any mail sent to the address for any machines in that zone will be sent to the mail server, which in turn will send it to the specific machines. For example, mail sent to a user on rabbit.mytrek.com will first be sent to turtle.mytrek.com, which will then send it on to rabbit.mytrek.com. In the following example, the host 192.168.0.1 (turtle.mytrek.com) is defined as the mail server for the mytrek.com domain:

mytrek.com. IN     MX   10   turtle.mytrek.com.

You could also inherit the domain name from the SOA record, leaving the domain name entry blank.

             IN     MX   turtle.mytrek.com.

You could use the IP address instead, but in larger networks, the domain name may be needed to search for and resolve the IP address of a particular machine, which could change.

mytrek.com. IN     MX   10   192.168.0.1

An MX record recognizes an additional field that specifies the ranking for a mail exchanger. If your zone has several mail servers, you can assign them different rankings in their MX records. The smaller number has a higher ranking. This way, if mail cannot reach the first mail server, it can be routed to an alternate server to reach the host. In the following example, mail for hosts on the mytrek.com domain is first routed to the mail server at 192.168.0.1 (turtle.mytrek.com), and if that fails, it is routed to the mail server at 192.168.0.2 (rabbit.mytrek.com).

mytrek.com. IN MX 10 turtle.mytrek.com.
            IN MX 20 rabbit.mytrek.com.

You can also specify a mail server for a particular host. In the following example, the mail server for lizard.mytrek.com is specified as rabbit.mytrek.com:

lizard.mytrek.com. IN      A        192.168.0.3
                   IN      MX  10   rabbit.mytrek.com.

 Aliases: CNAME

Resource records of type CNAME are used to specify alias names for a host in the zone. Aliases are often used for machines running several different types of servers, such as both Web and FTP servers. They are also used to locate a host when it changes its name. The old name becomes an alias for the new name. In the following example, ftp.mytrek.com is an alias for a machine actually called turtle.mytrek.com:

ftp.mytrek.com. IN CNAME turtle.mytrek.com.

The term CNAME stands for canonical name. The canonical name is the actual name of the host. In the preceding example, the canonical name is turtle.mytrek.com. The alias, also known as the CNAME, is ftp.mytrek.com. In a CNAME entry, the alias points to the canonical name. Aliases cannot be used for NS (name server) or MX (mail server) entries. For those records, you need to use the original domain name or IP address.

A more stable way to implement aliases is simply to create another address record for a host or domain. You can have as many hostnames for the same IP address as you want, provided they are certified. For example, to make www.mytrek.com an alias for turtle.mytrek.com, you only have to add another address record for it, giving it the same IP address as turtle.mytrek.com.

turtle.mytrek.com. IN A 192.168.0.1
www.mytrek.com. IN A 192.168.0.1

 Pointer Record: PTR

A PTR record is used to perform reverse mapping from an IP address to a host. PTR records are used in the reverse mapping files. The name entry holds a reversed IP address, and the data entry holds the name of the host. The following example maps the IP address 192.168.0.1 to turtle.mytrek.com:

1.1.168.192 IN PTR turtle.mytrek.com.

In a PTR record, you can specify just that last number segment of the address (the host address) and let DNS fill in the domain part of the address. In the next example, 1 has the domain address, 1.168.192, automatically added to give 1.1.168.192:

1 IN PTR turtle.mytrek.com.

 Host Information: HINFO, RP, MINFO, and TXT

The HINFO, RP, MINFO, and TXT records are used to provide information about the host. The RP record enables you to specify the person responsible for a certain host. The HINFO record provides basic hardware and operating system identification. The TXT record is used to enter any text you want. MINFO provides a host’s mail and mailbox information. These are used sparingly, as they may give too much information out about the server.

Zone Files

A DNS server uses several zone files covering different components of the DNS. Each zone uses two zone files: the principal zone file and a reverse mapping zone file. The zone file contains the resource records for hosts in the zone. A reverse mapping file contains records that provide reverse mapping of your domain name entries, enabling you to map from IP addresses to domain names. The name of the file used for the zone file can be any name. The name of the file is specified in the zone statement’s file entry in the named.conf file. If your server supports several zones, you may want to use a name that denotes the specific zone. Most systems use the domain name as the name of the zone file. For example, the zone mytrek.com would have a zone file with the same name and the extension db, as in mytrek.com.db. The zone file used in the following example is called mytrek.com.db. The reverse mapping file can also be any name, though it is usually the reverse IP address domain specified in its corresponding zone file. For example, in the case of mytrek.com.db zone file, the reverse mapping file might be called 192.168.0.db, the IP address of the mytrek.com domain defined in the mytrek.com.db zone file. This file would contain reverse mapping of all the host addresses in the domain, allowing their hostname addresses to be mapped to their corresponding IP addresses. In addition, BIND sets up a cache file and a zone files for the localhost. The cache file holds the resource records for the root name servers to which your name server connects. The cache file can be any name, although it is usually called named.ca. The localhost zone files hold reverse IP resource records for the local loopback interface, localhost. On Fedora, the localhost file is named.localhost, and its reverse mapping file is named.loopback. The localhost zone is configured by statements in the named.rfc1912.zones configuration file which is included in the named.conf file. The localhost addresses are configured according to the RFC 1912 Internet Protocol standard.

Once you have created your zone files, you should check their syntax with the named-checkzone tool. This tool requires that you specify both a zone and a zone file. In the following example, in the /var/named directory, the zone mytrek.com in the zone file mytrek.com.db is checked:

named-checkzone  mytrek.com mytrek.com.db

For slave servers, you can specify that a zone file be stored in a map file format. The map file format can be read and processed much faster than the text format normally used for zone files. Slave servers need to write a zone file to disk and later access it. Access can be speeded up by saving the file using memory mapping, saving the file as it exists in memory. The zone files saved in map format (memory mapping) can only be used on the computer they are generated on. To use the map format add the option masterfile-format map to the zone statement for the zone in the named.conf configuration file.

masterfile-format map;  

It is also possible to use the map file format for master servers, but you would have to convert the map files to text files to edit them. The named-compilezone tool can perform the conversions. 

Zone Files for Internet Zones

A zone file holds resource records that follow a certain format. The file begins with general directives to define default domains or to include other resource record files. These are followed by a single SOA record, name server and domain resource records, and then resource records for the different hosts. Comments begin with a semicolon and can be placed throughout the file. The @ symbol operates like a special macro, representing the domain name of the zone to which the records apply. The @ symbol is used in the first field of a resource or SOA record as the zone’s domain name. Multiple names can be specified using the * matching character. The first field in a resource record is the name of the domain to which it applies. If the name is left blank, the previous explicit name entry in another resource record is automatically used. This way, you can list several entries that apply to the same host without having to repeat the hostname. Any host or domain name used throughout this file that is not terminated with a period has the zone’s domain appended to it. For example, if the zone’s domain is mytrek.com and a resource record has only the name rabbit with no trailing period, the zone’s domain is automatically appended to it, giving you rabbit.mytrek.com.. Be sure to include the trailing period whenever you enter the complete fully qualified domain name, turtle.mytrek.com., for example.

 Directives

You can also use several directives to set global attributes. $ORIGIN sets a default domain name to append to address names that do not end in a period. $INCLUDE includes a file. $GENERATE can generate records whose domain or IP addresses differ only by an iterated number. The $ORIGIN directive is often used to specify the root domain to use in address records. Be sure to include the trailing period. The following example sets the domain origin to mytrek.com and will be automatically appended to the lizard host name that follows:

$ORIGIN   mytrek.com.
lizard   IN   A    192.168.0.2

 SOA Record

A zone file begins with an SOA record specifying the machine the name server is running on, among other specifications. The @ symbol is used for the name of the SOA record, denoting the zone’s domain name. After the SOA, the name server resource records (NS) are listed. Just below the name server records are resource records for the domain itself. Resource records for host addresses (A), aliases (CNAME), and mail exchangers (MX) follow. The following example shows a sample zone file, which begins with an SOA record and is followed by an NS record, resource records for the domain, and then resource records for individual hosts:

; Authoritative data for turle.mytrek.com
;
$TTL 86400
@ IN SOA turtle.mytrek.com. hostmaster.turtle.mytrek.com.(
                             93071200 ; Serial number
                                10800 ; Refresh 3 hours
                                 3600 ; Retry 1 hour
                              3600000 ; Expire 1000 hours
                              86400 ) ; Minimum 24 hours

             IN      NS        turtle.mytrek.com.
             IN      A         192.168.0.1
             IN      MX   10   turtle.mytrek.com.
             IN      MX   15   rabbit.mytrek.com.

turtle       IN      A         192.168.0.1
             IN      HINFO     PC-686 LINUX
gopher       IN      CNAME     turtle.mytrek.com.
ftp          IN      CNAME     turtle.mytrek.com.
www          IN      A         192.168.0.1

rabbit       IN      A         192.168.0.2

lizard       IN      A         192.168.0.3
             IN      HINFO     MAC MACOS

The first two lines are comments about the server for which this zone file is used. Notice that the first two lines begin with a semicolon. The class for each of the resource records in this file is IN, indicating these are Internet records. The SOA record begins with an @ symbol that stands for the zone’s domain. In this example, it is mytrek.com. Any host or domain name used throughout this file that is not terminated with a period has this domain appended to it. For example, in the following resource record, turtle has no period, so it automatically expands to turtle.mytrek.com. The same happens for rabbit and lizard. These are read as rabbit.mytrek.com and lizard.mytrek.com. Also, in the SOA, notice that the e-mail address for hostmaster uses a period instead of an @ symbol; @ is a special symbol in zone files and cannot be used for any other purpose.

Nameserver Record

The next resource record specifies the name server for this zone. Here, it is mytrek.com.. Notice the name for this resource record is blank. If the name is blank, a resource record inherits the name from the previous record. In this case, the NS record inherits the value of @ in the SOA record, its previous record. This is the zone’s domain, and the NS record specifies turtle.mytrek.com as the name server for this zone.

             IN   NS    turtle.mytrek.com.

Here the domain name is inherited. The entry can be read as the following. Notice the trailing period at the end of the domain name:

mytrek.com. IN   NS    turtle.mytrek.com.

 Address Record

The following address records set up an address for the domain itself. This is often the same as the name server, in this case, 192.168.0.1 (the IP address of turtle.mytrek.com). This enables users to reference the domain itself, rather than a particular host in it. A mail exchanger record follows that routes mail for the domain to the name server. Users can send mail to the mytrek.com domain and it will be routed to turtle.mytrek.com.

               IN    A     192.168.0.1

Here the domain name is inherited. The entry can be read as the following:

mytrek.com. IN   A     192.168.0.1

 Mail Exchanger Record

The next records are mail exchanger (MX) records listing turtle.mytrek.com and fast.mytrek.com as holding the mail servers for this zone. You can have more than one mail exchanger record for a host. More than one host may exist through which mail can be routed. These can be listed in mail exchanger records for which you can set priority rankings (a smaller number ranks higher). In this example, if turtle.mytrek.com cannot be reached, its mail is routed through rabbit.mytrek.com, which has been set up also to handle mail for the mytrek.com domain:

          IN     MX    100    turtle.mytrek.com.
          IN     MX    150    rabbit.mytrek.com.

Again the domain name is inherited. The entries can be read as the following:

mytrek.com.   IN      MX  100   turtle.mytrek.com.
mytrek.com.   IN      MX  150   rabbit.mytrek.com.

Address Record with Host Name

The following resource record is an address record (A) that associates an IP address with the fully qualified domain name turtle.mytrek.com. The resource record name holds only turtle with no trailing period, so it is automatically expanded to turtle.mytrek.com. This record provides the IP address to which turtle.mytrek.com can be mapped.

turtle   IN    A     192.168.0.1

 Inherited Names

Several resource records immediately follow that have blank names. These inherit their names from the preceding full record—in this case, turtle.mytrek.com. In effect, these records also apply to that host. Using blank names is an easy way to list additional resource records for the same host (notice that an apparent indent occurs). The first record is an information record, providing the hardware and operating system for the machine.

         IN    HINFO    PC-686 LINUX

 Alias Records

If you are using the same machine to run several different servers, such as Web, FTP, and Gopher servers, you may want to assign aliases to these servers to make accessing them easier for users. Instead of using the actual domain name, such as turtle.mytrek.com, to access the Web server running on it, users may find using the following is easier: for the Web server, www.mytrek.com; for the Gopher server, gopher.mytrek.com; and for the FTP server, ftp.mytrek.com. In the DNS, you can implement such a feature using alias records. In the example zone file, two CNAME alias records exist for the turtle.mytrek.com machine: FTP and Gopher. The next record implements an alias for www using another address record for the same machine. None of the name entries ends in a period, so they are appended automatically with the domain name mytrek.com. www.mytrek.com, ftp.mytrek.com, and gopher.mytrek.com are all aliases for turtle.mytrek.com. Users entering those URLs automatically access the respective servers on the turtle.mytrek.com machine.

gopher       IN      CNAME     turtle.mytrek.com.
ftp          IN      CNAME     turtle.mytrek.com.
www          IN      A         192.168.0.1

Address and mail exchanger records are then listed for the two other machines in this zone: rabbit.mytrek.com and lizard.mytrek.com. You could add HINFO, TXT, MINFO, or alias records for these entries.

 IPv6 Zone File Example

This is the same zone file using IPv6 addresses. The addresses are unique-local (FC00), instead of global (3), providing private network addressing. The loopback device is represented by the IPv6 address ::1. The AAAA IPv6 address records are used.

; Authoritative data for turle.mytrek.com, IPv6 version
$TTL 1d
@ IN SOA turtle.mytrek.com. hostmaster.turtle.mytrek.com.(
                             93071200 ; Serial number
                                10800 ; Refresh 3 hours
                                 3600 ; Retry 1 hour
                              3600000 ; Expire 1000 hours
                              86400 ) ; Minimum 24 hours

             IN      NS        turtle.mytrek.com.
             IN      AAAA        FC00::8:800:200C:417A
             IN      MX   10   turtle.mytrek.com.
             IN      MX   15   rabbit.mytrek.com.

turtle       IN      AAAA        FC00::8:800:200C:417A
             IN      HINFO     PC-686 LINUX
gopher       IN      CNAME     turtle.mytrek.com.
ftp          IN      CNAME     turtle.mytrek.com.
www          IN      AAAA        FC00::8:800:200C:417A

rabbit       IN      AAAA        FC00::FEDC:BA98:7654:3210

lizard       IN      AAAA        FC00::E0:18F7:3466:7D
             IN      HINFO     MAC MACOS

BIND 9 Reverse Mapping File

Reverse name lookups are enabled using a reverse mapping file. Reverse mapping files map fully qualified domain names to IP addresses. This reverse lookup capability is unnecessary, but it is convenient to have. With reverse mapping, when users access remote hosts, their domain name addresses can be used to identify their own host, instead of only the IP address. The name of the file can be anything you want. On most current distributions, it is the zone’s domain address (the network part of a zone’s IP address). For example, the reverse mapping file for a zone with the IP address of 192.168.0.1 is 192.168.0. It's full pathname would be something like /var/named/192.168.0.db. On some systems using older implementations of BIND, the reverse mapping filename may consist of the root name of the zone file with the extension .rev. For example, if the zone file is called mytrek.com, the reverse mapping file would be called something like mytrek.rev.

 IPv4 in-addr.arpa Reverse Mapping Format

In IPv4, the zone entry for a reverse mapping in the named.conf file uses a special domain name consisting of the IP address in reverse, with an in-addr.arpa extension. This reverse IP address becomes the zone domain referenced by the @ symbol in the reverse mapping file. For example, the reverse mapping zone name for a domain with the IP address of 192.168.43 would be 43.168.192.in-addr.arpa. In the following example, the reverse domain name for the domain address 192.168.0 is 1.168.192.in-addr.arpa:

zone "1.168.192.in-addr.arpa" in {
          type master;
          file "192.168.0.db";
          };

A reverse mapping file begins with an SOA record, which is the same as that used in a forward mapping file. Resource records for each machine defined in the forward mapping file then follow. These resource records are PTR records that point to hosts in the zone. These must be actual hosts, not aliases defined with CNAME records. Records for reverse mapping begin with a reversed IP address. Each segment in the IP address is sequentially reversed. Each segment begins with the host ID, followed by reversed network numbers.

; reverse mapping of domain names 1.168.192.in-addr.arpa
;
$TTL 86400
@ IN SOA turtle.mytrek.com. hostmaster.turtle.mytrek.com.(
                        92050300 ; Serial (yymmddxx format)
                           10800 ; Refresh 3hHours
                            3600 ; Retry 1 hour
                         3600000 ; Expire 1000 hours
                         86400 ) ; Minimum 24 hours

@            IN    NS       turtle.mytrek.com.
1            IN    PTR      turtle.mytrek.com.
2.1.168.192  IN    PTR      rabbit.mytrek.com.
3            IN    PTR      lizard.mytrek.com.

If you list only the host ID with no trailing period, the zone domain is automatically attached. In the case of a reverse mapping file, the zone domain as specified in the zone statement is the domain IP address backward. The 1 expands to 1.1.168.192. In the following example, turtle and lizard inherit the domain IP address, whereas rabbit has its address explicitly entered:

IPv6 IP6.ARPA Reverse Mapping Format

In IPv6, reverse mapping can be handled either with the current IP6.ARPA domain format, or with the older IP6.INT format. With IP6.ARPA, the address is represented by a bit-level representation that places the hexadecimal address within brackets. The first bracket is preceded by a backslash. The address must be preceded by an x indicating that it is a hexadecimal address. Following the address is a number indicating the number of bits referenced. In a 128-bit address, usually the first 64 bits reference the network address and the last 64 bits are for the interface address. The following example shows the network and interface addresses for lizard.

FC00:0000:0000:0000:00E0:18F7:3466:007D  lizard IPv6 address
\[xFC00000000000000/64]                  lizard network address
\[x00E018F73466007D/64]                  lizard interface address

The zone entry for a reverse mapping in the named.conf file with an IP6.ARPA extension would use the bit-level representation for the network address.

zone "\[xfc00000000000000/64].IP6.ARPA" in {
          type master;
          file "fec.ip6.arpa";
          };

A reverse mapping file then uses the same bit-level format for the interface addresses.

$TTL 1d
@ IN SOA turtle.mytrek.com. hostmaster.turtle.mytrek.com.(
                        92050300 ; Serial (yymmddxx format)
                           10800 ; Refresh 3hHours
                            3600 ; Retry 1 hour
                         3600000 ; Expire 1000 hours
                         86400 ) ; Minimum 24 hours

@                           IN    NS       turtle.mytrek.com.
\[x00080800200C417A/64]     IN    PTR      turtle.mytrek.com.
\[xFEDCBA9876543210/64]     IN    PTR      rabbit.mytrek.com.
\[x00E018F73466007D/64]     IN    PTR      lizard.mytrek.com.

IPv6 IP6.INT Reverse Mapping Format

The older IP6.INT format uses a nibble format for the IPv6 address. This has since been replaced by the IPv6.ARPA format. The hexadecimal address is segmented into each hex number, separated by a period and written in reverse. This gives you 32 hex numbers in reverse order. The IP6.INT version for the lizard address are shown here:

FC00:0000:0000:0000:00E0:18F7:3466:007D   lizard IPv6 address
0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f           lizard network address
D.7.0.0.6.6.4.3.7.F.8.1.0.E.0.0           lizard interface address

The zone entry for a reverse mapping in the named.conf file with an IP6.INT extension would use the reverse nibble format for the network address.

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.IP6.INT" in {
          type master;
          file "fec.ip6.int";
          };

The reverse zone file then uses the reverse nibble format for each interface address.

$TTL 1d
@ IN SOA turtle.mytrek.com. hostmaster.turtle.mytrek.com.(
                        92050300 ; Serial (yymmddxx format)
                           10800 ; Refresh 3hHours
                            3600 ; Retry 1 hour
                         3600000 ; Expire 1000 hours
                         86400 ) ; Minimum 24 hours

$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f  IN  NS  turtle.mytrek.com.
A.7.1.4.C.0.0.2.0.0.8.0.8.0.0.0   IN    PTR      turtle.mytrek.com.
0.1.2.3.4.5.6.7.8.9.A.B.C.D.E.F   IN    PTR      rabbit.mytrek.com.
D.7.0.0.6.6.4.3.7.F.8.1.0.E.0.0   IN    PTR      lizard.mytrek.com.

RFC 1912 private address management: localhost

On Fedora, the zones for private address space, including localhost, is handled by the RFC 1912 configuration file, named.rfc1912.zones. This file is read directly by the named.conf file, including it as part of your BIND configuration. It defines zones for localhost, localhost.localdomain, and the localhost reverse mapping zones for both IPv4 and IPv6 addressing.

Localhost zone file: named.localhost

The named.localhost zone file implements mapping for the local loopback interface known as localhost. This file includes support for both for IPv4 and for IPv6 addressing. The IPv4 address for localhost is 127.0.0.1, and the IPv6 address is ::1. These are special addresses that function as the local address for your machine. It allows a machine to address itself.

The IPv4 address has the type A and the address 127.0.0.1, whereas the IPv6 address has the type AAAA and the address ::1.

      A     127.0.0.1
     AAAA  ::1

The named.localhost zone file is shown here.

named.localhost

$TTL 1D
@     IN SOA     @ rname.invalid. (
                         0     ; serial
                         1D     ; refresh
                         1H     ; retry
                         1W     ; expire
                         3H )  ; minimum
     NS     @
     A     127.0.0.1
     AAAA  ::1

named.rfc1912.zones

// named.rfc1912.zones:
// Provided by Red Hat caching-nameserver package
// ISC BIND named zone configuration for zones recommended by
// RFC 1912 section 4.1 : localhost TLDs and address zones
// and http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt
// (c)2007 R W Franks
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

zone "localhost.localdomain" IN {
     type master;
     file "named.localhost";
     allow-update { none; };
};

zone "localhost" IN {
     type master;
     file "named.localhost";
     allow-update { none; };
};

zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
     type master;
     file "named.loopback";
     allow-update { none; };
};

zone "1.0.0.127.in-addr.arpa" IN {
     type master;
     file "named.loopback";
     allow-update { none; };
};

zone "0.in-addr.arpa" IN {
     type master;
     file "named.empty";
     allow-update { none; };
};

Localhost Reverse Mapping: named.loopback

A localhost reverse mapping file implements reverse mapping for the local loopback interface known as localhost, This file is given the name named.loopback  It is referenced by both the IPv4 and IPv6 reverse mapping zone statements.

In the IPv4 zone statement for this file, the name of the zone is 0.0.127.in-addr.arpa. The domain part of the IP address is entered in reverse order, with in-addr.arpa appended to it, 0.0.127.IN-addr.arpa. The named.rfc1912.zones entry is shown here:

zone "0.0.127.in-addr.arpa" {
           type master;
           file "named.loopback";
           allow-update { none; };
  };

For IPv6 zone statement, the Fedora implementation uses the nibble format for the reverse mapping address:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.

The IPv6 localhost zone statement is shown here:

zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
     type master;
     file "named.loopback";
     allow-update { none; };
};

The named.loopback zone file supports both IPv4 and IPv6 addresses. The NS record specifies the name server localhost should use. This file has a PTR record that maps the IP address to the localhost. The contents of the named.localhost file is shown here. Notice the trailing periods for localhost:

$TTL 1D
@       IN SOA  @  rname.invalid. (
                         0     ; serial
                         1D     ; refresh
                         1H     ; retry
                         1W     ; expire
                         3H )     ; minimum
        NS          @
        A           127.0.0.1
        AAAA        ::1
        PTR         localhost.

BIND 9 Subdomains and Slaves

Adding a subdomain to a DNS server is a simple matter of creating an additional master entry in the named.conf file, and then placing name server and authority entries for that subdomain in your primary DNS server’s zone file. The subdomain, in turn, has its own zone file with its SOA record and entries listing hosts, which are part of its subdomain, including any of its own mail and news servers.

Subdomain Zones

The name for the subdomain could be a different name altogether or a name with the same suffix as the primary domain. In the following example, the subdomain is called beach.mytrek.com. It could just as easily be called mybeach.com. The name server to that domain is on the host crab.beach.mytrek.com, in this example. Its IP address is 192.168.0.33, and its zone file is beach.mytrek.com. The beach.mytrek.com zone file holds DNS entries for all the hosts being serviced by this name server. The following example shows zone entries for its named.conf:

zone "beach.mytrek.com" {
          type master;
          file "beach.mytrek.com.db";
          };

zone "1.168.192.in-addr.arpa" {
          type master;
          file "192.168.0.db";
          };

Subdomain Records

On the primary DNS server, in the example turtle.mytrek.com, you would place entries in the master zone file to identify the subdomain server’s host and designate it as a name server. Such entries are also known as glue records. In this example, you would place the following entries in the mytrek.com zone file on turtle.mytrek.com:

beach.mytrek.com.   IN    NS    beach.mytrek.com.
beach.mytrek.com.   IN    A     192.168.0.33.

URL references to hosts serviced by beach.mytrek.com can now be reached from any host serviced by mytrek.com, which does not need to maintain any information about the beach.mytrek.com hosts. It simply refers such URL references to the beach.mytrek.com name server.

Slave Servers

A slave DNS server is tied directly to a master DNS server and periodically receives DNS information from it. You use a master DNS server to configure its slave DNS servers automatically. Any changes you make to the master server are automatically transferred to its slave servers. This transfer of information is called a zone transfer. Zone transfers are automatically initiated whenever the slave zone’s refresh time is reached or the slave server receives a notify message from the master. The refresh time is the second argument in the zone’s SOA entry. A notify message is automatically sent by the master whenever changes are made to the master zone’s configuration files and the named daemon is restarted. In effect, slave zones are automatically configured by the master zone, receiving the master zone’s zone files and making them their own.

Slave Zones

Using the previous examples, suppose you want to set up a slave server on rabbit.mytrek.com. Zone entries, as shown in the following example, are set up in the named.conf configuration file for the slave DNS server on rabbit.mytrek.com. The slave server is operating in the same domain as the master, and so it has the same zone name, mytrek.com. Its SOA file is named slave.mytrek.com.db. The slave zone files will be located in the slaves subdirectory. The term “slave” in the filename is merely a convention that helps identify it as a slave server configuration file. The masters statement lists its master DNS server—in this case, 192.168.0.1. Whenever the slave needs to make a zone transfer, it transfers data from that master DNS server. The entry for the reverse mapping file for this slave server lists its reverse mapping file as slave.192.168.0.db.

zone "mytrek.com" {
         type slave;
         file "slave.mytrek.com.db";
         masters { 192.168.0.1;
         };

zone "1.168.192.in-addr.arpa" {
          type slave;
          file "slave.192.168.0.db";
          masters { 192.168.0.1;
          };

Slave Records

On the master DNS server, the master SOA zone file has entries in it to identify the host that holds the slave DNS server and to designate it as a DNS server. In this example, you would place the following in the mytrek.com zone file:

         IN       NS       192.168.0.2

You would also place an entry for this nameserver in the mytrek.com reverse mapping file:

         IN       NS       192.168.0.2

Controlling Transfers

The master DNS server can control which slave servers can transfer zone information from it using the allow-transfer statement. Place the statement with the list of IP addresses for the slave servers to which you want to allow access. Also, the master DNS server should be sure its notify option is not disabled. The notify option is disabled by a “notify no” statement in the options or zone named.conf entries. Simply erase the “no” argument to enable notify.

Incremental Zone Transfers

With BIND versions 8.2.2 and 9.0, BIND now supports incremental zone transfers (IXFR). Previously, all the zone data would be replaced in an update, rather than changes such as the addition of a few resource records simply being edited in. With incremental zone transfers, a database of changes is maintained by the master zone. Then only the changes are transferred to the slave zone, which uses this information to update its own zone files. To implement incremental zone transfers, you have to turn on the maintain-ixfr-base option in the options section.

maintain-ixfr-base yes;

You can then use the ixfr-base option in a zone section specify a particular database file to hold changes.

ixfr-base “db.mytrek.com.ixfr”;

IP Virtual Domains

IP-based virtual hosting allows more than one IP address to be used for a single machine. If a machine has two registered IP addresses, either one can be used to address the machine. If you want to treat the extra IP address as another host in your domain, you need only create an address record for it in your domain’s zone file. The domain name for the host would be the same as your domain name. If you want to use a different domain name for the extra IP, however, you have to set up a virtual domain for it. This entails creating a new zone statement for it with its own zone file. For example, if the extra IP address is 192.168.0.42 and you want to give it the domain name sail.com, you must create a new zone statement for it in your named.conf file with a new zone file. The zone statement would look something like this. The zone file is called sail.com:

zone "sail.com" in {
           type master;
           file "sail.com.db";
           };

In the sail.com file, the name server name is turtle.mytrek.com and the e-mail address is hostmaster@turtle.mytrek.com. In the name server (NS) record, the name server is turtle.mytrek.com. This is the same machine using the original address that the name server is running as. turtle.mytrek.com is also the host that handles mail addressed to sail.com (MX). An address record then associates the extra IP address 192.168.0.42 with the sail.com domain name. A virtual host on this domain is then defined as jib.sail.com. Also, www and ftp aliases are created for that host, creating www.sail.com and ftp.sail.com virtual hosts.

; Authoritative data for sail.com
;
$TTL 1d
@ IN SOA turtle.mytrek.com. hostmaster.turtle.mytrek.com. (
                               93071200 ; Serial (yymmddxx)
                                  10800 ; Refresh 3 hours
                                   3600 ; Retry 1 hour
                                3600000 ; Expire 1000 hours
                                86400 ) ; Minimum 24 hours

        IN      NS         turtle.mytrek.com.
        IN      MX   10    turtle.mytrek.com.
        IN      A          192.168.0.42 ;address of the sail.com domain

jib     IN      A         192.168.0.42
www     IN      A         jib.sail.com.
ftp     IN      CNAME     jib.sail.com.

In your reverse mapping file (/var/named/1.168.192), add PTR records for any virtual domains.

42.1.168.192      IN     PTR     sail.com.
42.1.168.192      IN     PTR     jib.sail.com.

You also have to configure your network connection to listen for both IP addresses on your machine.

BIND 9 Cache File

The cache file is used to connect the DNS server to root servers on the Internet. The file can be any name. On Fedora, the cache file is called named.ca. Other systems may call the cache file named.cache or roots.hints. The cache file is usually a standard file installed by your BIND software, which lists resource records for designated root servers for the Internet. You can obtain a current version of the named.ca file from the https://rs.internic.net FTP site. The following example shows sample entries taken from the named.ca file:

; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107

If you are creating an isolated intranet, you need to create your own root DNS server until you connect to the Internet. In effect, you are creating a fake root server. This can be another server on your system pretending to be the root or the same name server.

Dynamic Update: DHCP and Journal Files

There are situations where you will need to have zones updated dynamically. Instead of your manually editing a zone file to make changes in a zone, an outside process updates the zone, making changes and saving the file automatically. Dynamic updates are carried out both by master zones updating slave zones and by DHCP servers providing IP addresses they generated for hosts to the DNS server.

A journal file is maintained recording all the changes made to a zone, having a .jnl extension. Should a system crash occur, this file is read to implement the most current changes. Should you want to manually update a dynamically updated zone, you will need to erase its journal file first; otherwise, your changes would be overwritten by the journal file entries.

You allow a zone to be automatically updated by specifying the allow-update option. This option indicates the host that can perform the update.

allow-update {turtle.mytrek.com;};

Alternatively, for master zones, you can create a more refined set of access rules using the update-policy statement. With the update-policy statement, you can list several grant and deny rules for different hosts and types of hosts.

TSIG Signatures and Updates

With BIND 9.x, TSIG signature names can be used instead of host names or IP addresses for both allow-update and update-policy statements (see the following sections on TSIG). Use of TSIG signatures implements an authentication of a host performing a dynamic update, providing a much greater level of security. For example, to allow a DHCP server to update a zone file, you would place an allow-update entry in the zone statement listed in the named.conf file.

The TSIG key is defined in a key statement, naming the key previously created by the dnssec-keygen command. The algorithm is HMAC-MD5, and the secret is the encryption key listed in the .private file generated by dnssec-keygen.

key mydhcpserver {
algorithm HMAC-MD5;
secret "ONQAfbBLnvWU9H8hRqq/WA==";
};

The key name can then be used in an allow-update or allow-policy statement to specify a TSIG key.

allow-update { key mydhcpserver;};

 Manual Updates: nsupdate

You can use the update procedure to perform any kind of update you want. You can perform updates manually or automatically using a script. For DHCP updates, the DHCP server is designed to perform dynamic updates of the DNS server. You will need to configure the DHCP server appropriately, specifying the TSIG key to use and the zones to update.

You can manually perform an update using the nsupdate command, specifying the file holding the key with the -k option.

nsupdate -k myserver.private

At the prompt, you can use nsupdate commands to implement changes. You match on a record using its full or partial entry. To update a record, you would first delete the old one and then add the changed version, as shown here:

update delete rabbit.mytrek.com. A 192.168.0.2
update add rabbit.mytrek.com. A 192.168.0.44

DNS Security: Access Control Lists, TSIG, and DNSSEC

DNS security currently allows you to control specific access by hosts to the DNS server, as well as providing encrypted communications between servers and authentication of DNS servers. With access control lists, you can determine who will have access to your DNS server. The DNS Security Extensions (DNSSEC), included with BIND 9.x, provide private/public key–encrypted authentication and transmissions. TSIGs (transaction signatures) use shared private keys to provide authentication of servers to secure actions such as dynamic updates between a DNS server and a DHCP server.

 Access Control Lists

To control access by other hosts, you use access control lists, implemented with the acl statement. allow and deny options with access control host lists enable you to deny or allow access by specified hosts to the name server. With allow-query, you can restrict queries to specified hosts or networks. Normally this will result in a response saying that access is denied. You can further eliminate this response by using the blackhole option in the options statement.

You define an ACL with the acl statement followed by the label you want to give the list and then the list of addresses. Addresses can be IP addresses, network addresses, or a range of addresses based on CNDR notation. You can also use an ACL as defined earlier. The following example defines an ACL called mynet:

acl mynet { 192.168.0.1; 192.168.0.2; };

If you are specifying a range, such as a network, you also add exceptions to the list by preceding such addresses with an exclamation point (!). In the following example, the myexceptions ACL lists all those hosts in the 192.168.0.0 network, except for 192.168.0.3:

acl myexceptions {192.168.0.0; !192.168.0.3; };

Four default ACLs are already defined for you. You can use them wherever an option uses a list of addresses as an argument. These are any for all hosts, none for no hosts, localhost for all local IP addresses, and localnet for all hosts on local networks served by the DNS server.

Once a list is defined, you can then use it with the allow-query, allow-transfer, allow-recursion, and blackhole options in a zone statement to control access to a zone. allow-query specifies hosts that can query the DNS server. allow-transfer is used for master/slave zones, designating whether update transfers are allowed. allow-recursion specifies those hosts that can perform recursive queries on the server. The blackhole option will deny contact from any hosts in its list, without sending a denial response. In the next example, an ACL of mynet is created. Then in the mytrek.com zone, only these hosts are allowed to query the server. As the server has no slave DNS servers, zone transfers are disabled entirely. The blackhole option denies access from the myrejects list, without sending any rejection notice.

acl mynet { 192.168.0.0; };
acl myrejects { 10.0.0.44; 10.0.0.93; };

zone "mytrek.com" {
         type master;
         file "mytrek.com";
         allow-query { mynet; };
         allow-recursion { mynet; };
         allow-transfer { none; };
         blackhole {myrejects};
         };

Secret Keys

Different security measures will use encryption keys generated with the dnssec-keygen command. You can use dnssec-keygen to create different types of keys, including zone (ZONE), host (HOST), and user (USER) keys. You specify the type of key with the -n option. A zone key will require the name ZONE and the name of the zone’s domain name. A zone key is used in DNSSEC operations. The following example creates a zone key for the mytrek.com zone:

dnssec-keygen -n ZONE mytrek.com.

To create a host key, you would use the HOST type. HOST keys are often used in TSIG operations.

dnssec-keygen -n HOST turtle.mytrek.com.

You can further designate an encryption algorithm (-a) and key size (-b). Use the -h option to obtain a listing of the dnssec-keygen options. Currently, you can choose from RSA, DSA, HMAC-MD5, and DH algorithms. The bit range will vary according to the algorithm. RSA ranges from 512 to 4096, and HMAC-MD5 ranges from 1 to 512. The following example creates a zone key using a 768-bit key and the DSA encryption algorithm:

dnssec-keygen -a DSA -b 768 -n ZONE mytrek.com.

The dnssec-keygen command will create public and private keys, each in corresponding files with the suffixes .private and .key. The .key file is a KEY resource record holding the public key. For DNSSEC, the private key is used to generate signatures for the zone, and the public key is used to verify the signatures. For TSIG, a shared private key generated by the HMAC-MD5 algorithm is used instead of a public/private key pair.

DNSSEC

DNSSEC provides encrypted authentication to DNS. With DNSSEC, you can create a signed zone that is securely identified with an encrypted signature. This form of security is used primarily to secure the connections between master and slave DNS servers so that a master server transfers update records only to authorized slave servers and does so with a secure encrypted communication. Two servers that establish such a secure connection do so using a pair of public and private keys. In effect, you have a parent zone that can securely authenticate child zones, using encrypted transmissions. This involves creating zone keys for each child and having those keys used by the parent zone to authenticate the child zones.

Once you have configured DNSSEC you can enable it by placing the dnssec-enable option in the /etc/named.conf file. 

dnssec-enable yes;

Zone Keys

You generate a zone key using the dnssec-keygen command and specifying the zone type, ZONE, with the -n option. For the key name, you use the zone’s domain name. The following example creates a zone key for the mytrek.com zone:

dnssec-keygen -n ZONE mytrek.com.

You can further designate an encryption algorithm (-a) and a key size (-b). Use the -h option to obtain a listing of the dnssec-keygen options. Since you are setting up a public/private key pair, you should choose either the RSA or DSA algorithm. The bit range will vary according to the algorithm. RSA ranges from 512 to 4096, and DSA ranges from 512 to 1024. The following example creates a zone key using a 768-bit key and the DSA encryption algorithm:

dnssec-keygen -a DSA -b 768 -n ZONE mytrek.com.

The dnssec-keygen command will create public and private keys, each in corresponding files with the suffixes .private and .key. The private key is used to generate signatures for the zone, and the public key is used to verify the signatures. The .key file is a KEY resource record holding the public key. This is used to decrypt signatures generated by the corresponding private key. You add the public key to the DNS configuration file, named.conf, using the $INCLUDE statement to include the .key file.

DNSSEC Resource Records

In the zone file, you then use three DNSSEC DNS resource records to implement secure communications for a given zone: KEY, SIG, and NXT. In these records, you use the signed keys for the zones you have already generated. The KEY record holds public keys associated with zones, hosts, or users. The SIG record stores digital signatures and expiration dates for a set of resource records. The NXT record is used to determine that a resource record for a domain does not exist. In addition, several utilities let you manage DNS encryption. With the dnskeygen utility, you generated the public and private keys used for encryption. dnssigner signs a zone using the zone’s private key, setting up authentication.

mytrek.com. KEY 0x4101 3 3 (
AvqyXgKk/uguxkJF/hbRpYzxZFG3x8EfNX389l7GX6w7rlLy
BJ14TqvrDvXr84XsShg+OFcUJafNr84U4ER2dg6NrlRAmZA1
jFfV0UpWDWcHBR2jJnvgV9zJB2ULMGJheDHeyztM1KGd2oGk
Aensm74NlfUqKzy/3KZ9KnQmEpj/EEBr48vAsgAT9kMjN+V3
NgAwfoqgS0dwj5OiRJoIR4+cdRt+s32OUKsclAODFZTdtxRn
vXF3qYV0S8oewMbEwh3trXi1c7nDMQC3RmoY8RVGt5U6LMAQ
KITDyHU3VmRJ36vn77QqSzbeUPz8zEnbpik8kHPykJZFkcyj
jZoHT1xkJ1tk )

To secure a DNS zone with DNSSEC, you first use dnskeygen to create public and private keys for the DNS zone. Then use dnssigner to create an authentication key. In the DNS zone file, you enter a KEY resource record in which you include the public key. The public key will appear as a lengthy string of random characters. For the KEY record, you enter the domain name followed by the KEY and then the public key.

For authentication, you can sign particular resource records for a given domain or host. Enter the domain or host followed by the term SIG and then the resource record’s signature.

mytrek.com. SIG KEY 3 86400 19990321010705 19990218010705 4932 com. (
Am3tWJzEDzfU1xwg7hzkiJ0+8UQaPtlJhUpQx1snKpDUqZxm
igMZEVk= )

The NXT record lets you negatively answer queries.

mytrek.com. NXT ftp.mytrek.com. A NS SOA MX SIG KEY NXT

Signing Keys

To set up secure communications between a parent (master) DNS server and a child (slave) DNS server, the public key then needs to be sent to the parent zone. There, the key can be signed by the parent. As you may have more than zone key, you create a keyset using the dnssec-makekeyset command. This generates a file with the extension .keyset that is then sent to the parent. The parent zone then uses the dnssec-signkey command to sign a child’s keyset. This generates a file with the prefix signedkey-. This is sent back to the child and now contains both the child’s keyset and the parent’s signatures. Once the child has the signedkey- files, the dnssec-signedzone command can be used to sign the zone. The dnssec-signedzone command will generate a file with the extension .signed. This file is then included in the named.conf file with the INCLUDE operation. The trusted-keys statement needs to list the public key for the parent zone.

DNSSEC Validation

DNSSEC can also operate as a validating resolver for external servers.  This is the case when DNSSEC is used as a caching-only server.  DNS validation is enabled with the dnssec-validation option.  On Fedora, the validation is implemented using DNSSEC look-aside validation (DLV), the dnssec-lookaside option.  Instead of servers having to maintain their own keys at the top of their zone, they use the one provided by the ISC DLV registry.  On Fedora, the location of the DLV key file specified by the bindkeys-file option, which is located at /etc/named.iscdlv.key.

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";

Dynamic Trust Anchor Management

Dynamic Trust Anchor Management (RFC 5011) allows DNSSEC to update critical keys automatically.  It is implemented using a validating resolver, which accesses keys kept in the directory specified by the managed-keys-directory statement. Keys can be specified with the managed-keys statement is the same as the trusted-keys statement, except that it updates keys automatically. 

The managed keys are held in a managed key database implemented as a zone file named managed-keys.bind. The managed-keys-directory statement specifies the location of this directory, /var/named/dynamic. The options clause at the head of the named.conf file will hold the following statement.

managed-keys-directory "/var/named/dynamic";

By default, the denssec-lookaside option is set to auto, which will include the key provided by the ISC DLV registry, dlv.isc.org, in the managed-keys.bind database.

You set up a key for dynamic trust anchor management with Key Signing Keys (KSK) implemented using dnssec-sign to create the keys, and dnssec-signzone to add the key to a zone, but not sign it. The key can then be used for an automatic update. The following example creates a KSK key (-f KSK) to be published to the zone now (-P now) and sets the key activation date to three months (-A now+3mo). The dnssec-signzone operation uses smart signing (-S) which will publish the key. 

dnssec-keygen -K keys -f KSK -P now -A now+3mo turtle.mytrek.com
dnssec-signzone -S -K keys turtle.mytrek.com

TSIG Keys

TSIG (transaction signatures) also provide secure DNS communications, but they share the private key instead of a private/public key pair. They are usually used for communications between two local DNS servers, and to provide authentication for dynamic updates such as those between a DNS server and a DHCP server.

Generating TSIG keys

To create a TSIG key for your DNS server, you use the dnssec-keygen command as described earlier. Instead of using the same keys you use for DNSSEC, you create a new set to use for transaction signatures. For TSIG, a shared private key is used instead of a public/private key pair. For a TSIG key, you would use an HMAC-MD5 algorithm that generates the same key in the both the .key and .private files. Use the -a option to specify the HMAC-MD5 algorithm to use and the -b option for the bit size. (HMAC-MD5 ranges from 1 to 512.) Use the -n option to specify the key type, in this case, HOST for the host name. The bit range will vary according to the algorithm. The following example creates a host key using a 128-bit key and the HMAC-MD5 encryption algorithm:

dnssec-keygen -a HMAC-MD5 -b 128 -n HOST turtle.mytrek.com

This creates a private key and a public key, located in the .key and .private files. In a TSIG scheme, both hosts would use the same private key for authentication. For example, to enable a DHCP server to update a DNS server, both would need the private (secret) key for a TSIG authentication. The HMAC-MD5 key is used as a shared private key, generating both the same private and public keys in the .key and .private files.

The Key Statement

You then specify a key in the named.conf file with the key statement. For the algorithm option, you list the HMAC-MD5 algorithm, and for the secret option, you list the private key. This key will be listed in both the .private and .key files. The preceding example would generate key and private files called Kturtle.mytrek.com.+157.43080.key and Kturtle.mytrek.com.+157.43080.private. The contents of the .key file consist of a resource record shown here:

turtle.mytrek.com. IN KEY 512 3 157 ONQAfbBLnvWU9H8hRqq/WA==

The contents of the private file show the same key along with the algorithm:

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: ONQAfbBLnvWU9H8hRqq/WA==

Within the named.conf file, you then name the key using a key statement:

key myserver {
algorithm HMAC-MD5;
secret "ONQAfbBLnvWU9H8hRqq/WA==";
};

The key’s name can then be used to reference the key in other named statements, such as allow-update statements:

allow-update myserver;

The DNS server or DHCP server with which you are setting up communication will also have to have the same key. See the earlier section “Dynamic Update: DHCP and Journal Files”. For communication between two DNS servers, each would have to have a server statement specifying the shared key. In the following example, the named.conf file for the DNS server on 192.168.0.1 would have to have the following server statement to communicate with the DNS server on 10.0.0.1, using the shared myserver key. The named.conf file on the 10.0.0.1 DNS server would have to have a corresponding server statement for the 192.168.0.1 server.

server 10.0.0.1 {  keys (myserver;}; };

Split DNS

BIND 9.x allows you to divide DNS space into internal and external views. This organization into separate views is referred to as split DNS. Such a configuration is helpful to manage a local network that is connected to a larger network, such as the Internet. Your internal view would include DNS information on hosts in the local network, whereas an external view would show only the part of the DNS space that is accessible to other networks. DNS views are often used when you have a local network that you want to protect from a larger network such as the Internet. In effect, you protect DNS information for hosts on a local network from a larger external network such as the Internet.

Internal and External Split DNS

The internal DNS servers will hold DNS information about local hosts. The external DNS view maintains connections to the Internet through a gateway as well as manages DNS information about any local hosts that allow external access, such as FTP or Web sites. The gateways and Internet-accessible sites make up the external view of hosts on the network. The internal view handles all queries to the local hosts or subdomains. Queries to external hosts such as Internet sites are sent to the external servers, which then forward them on to the Internet. Queries sent to those local hosts that operate external servers such as Internet FTP and Web sites are sent to the external DNS view for processing. Mail sent to local hosts from the Internet is handled first by the external servers, which then forward messages on to the internal servers. With a split DNS configuration, local hosts can access other local hosts, Internet sites, and local hosts maintaining Internet servers. Internet users, on the other hand, can access only those hosts open to the Internet (served by the external view) such as those with Internet servers like FTP and HTTP. Internet users can, however, send mail messages to any of the local hosts, internal and external.

You can also use DNS views to manage connections between a private network that may use only one Internet address to connect its hosts to the Internet. In this case, the internal view holds the private addresses (192.168...), and the external view connects a gateway host with an Internet address to the Internet. This adds another level of security, providing a result similar to IP masquerading.

Configuring Views for separate servers

DNS views are configured with the allow statements such as allow-query and allow-transfer. With these statements, you can specify the hosts that a zone can send and receive queries and transfers to and from. For example, the internal zone could accept queries from other local hosts, but not from local hosts with external access such as Internet servers. The local Internet servers, though, can accept queries from the local hosts. All Internet queries are forwarded to the gateway. In the external configuration, the local Internet servers can accept queries from anywhere. The gateways receive queries from both the local hosts and the local Internet servers.

In the following examples, a network of three internal hosts and one external host is set up into a split view. There are two DNS servers: one for the internal network and one for external access, based on the external host. In reality, these make up one network but they are split into two views. The internal view is known as mygolf.com, and the external as greatgolf.com. In each configuration, the internal hosts are designated in ACL-labeled internals, and the external host is designated in ACL-labeled externals. Should you want to designate an entire IP address range as internal, you could simply use the network address, as in 192.168.0.0/24. You can also reference all hosts on a local network with the built-in ACL localnets.  In the options section, allow-query, allow-recursion, and allow-transfers restrict access within the network.

To implement a split DNS space, you can either set up different DNS servers for the internal and external views, or use the view statement for a single DNS server.

The following example shows only the configuration entries needed to implement an internal view. In the mygolf.com zone, queries and transfers are allowed only among internal hosts. The global allow-recursion option allows recursion among internals.

Internal DNS server

acl internals { 192.168.0.1; 192.168.0.2; 192.168.0.3; };
acl externals {10.0.0.1;};
options {
         forward only;
         forwarders {10.0.0.1;}; // forward to external servers
         allow-transfer { none; }; // allow-transfer to no one by default
         allow-query { internals; externals; };// restrict query access
         allow-recursion { internals; }; // restrict recursion to internals
         }
include "/etc/named.rfc1912.zones
zone "mygolf.com" {
              type master;
              file "mygolf.db";
              forwarders { };
              allow-query { internals; };
              allow-transfer { internals; } };

In the configuration for the external DNS server, the same ACLs are set up for internals and externals. In the options statement, recursion is now allowed for both externals and internals. In the mygolf.com zone, queries are allowed from anywhere, and recursion is allowed for externals and internals. Transfers are not allowed at all.

External DNS server

acl internals { 192.168.0.1; 192.168.0.2; 192.168.0.3; };
acl externals {10.0.0.1;};
options {
         allow-transfer { none; }; // allow-transfer to no one
         allow-query { internals; externals; };// restrict query access
         allow-recursion { internals; externals }; // restrict recursion
         };
zone "greatgolf.com" {
               type master;
               file "greatgolf.db";
               allow-query { any; };
               allow-transfer { internals; externals; };
            };

Split View on a single DNS server using view clauses

Instead of using two separate physical servers, you can use the view statement to configure split views on a single DNS server. If you use view statements, then all zone definitions have to be included in a view statement. The following is based on the DNS sample in the /usr/share/doc/BIND*/sample/etc directory for a named.conf file that uses views to define internal and external servers. Check this example for a detailed description of a views implementation. The internal server is labeled "internal" and the external servers as "external." For a caching-only server, you could use a view with the label "localhost_resolver", as used in the Fedora BIND example. You use the match-clients option to specify allowable clients. To restrict access to local networks you can use localnets. To allow access by any query, you use any. The recursion option can allow recursion access, allowing the DNS server to submit queries to other DNS servers it does not control. The internal view loads the named.rfc1912.zones file for localhost access. The external view allows access from any host, but does turns recursion off, responding only to queries to itself and the DNS servers it controls.

named.conf for split views

options {
     directory "/var/named"; // the default
     dump-file           "/var/named/data/cache_dump.db";
        statistics-file      "/var/named/data/named_stats.txt";
        memstatistics-file      "/var/named/data/named_mem_stats.txt";
      };

view  "internal"
       {
        match-clients {localnets};
        recursion yes;    
        include "/etc/named.root.hints";
        include "/etc/named.rfc1912.zones";
        zone "mygolf.com" {
              type master;
             file "mygolf.db";};

      };

view   "external"
       {
        match-clients { any; };
       recursion no;
      include "/etc/named.root.hints";
       zone "greatgolf.com" {
              type master;
              file "greatgolf.db";}
       };

Response Policy Zones (DNS RPZ): DNS Firewall

Response Policy Zones allow you to allow you to control the response you give to different clients or queries You can setup a policy for a specific zone that determines what responses to give for certain requests. Such zones are called Response Policy Zones (RPZ).  An RPZ zone can intercept and block an attack, in effect, setting up a zone based DNS Firewall. The RPZ zone contains rules, much like a firewall rule with a trigger and an action. DNS firewall is often used to block domains, preventing clients from accessing known malicious sites. For more information see "Building DNS Firewalls with Response Policy Zones", https://kb.isc.org/article/AA-00525/0.

16. Network Autoconfiguration with IPv6, DHCP 4

Many networks now provide either IPv6 autoconfiguration or the DHCP (Dynamic Host Configuration Protocol) service, which automatically provides network configuration for all connected hosts. Autoconfiguration can be either stateless, as in the case of IPv6, or stateful, as with DHCP. Stateless IPv6 autoconfiguration requires no independent server or source to connect to a network. It is a direct plug-and-play operation, where the hardware network interfaces and routers can directly determine the correct addresses. DCHP is an older method that requires a separate server to manage and assign all addresses. Should this server ever fail, hosts cannot connect.

With the DHCP protocol, an administrator uses a pool of IP addresses from which the administrator can assign an IP address to a host as needed. The protocol can also be used to provide all necessary network connection information such as the gateway address for the network or the netmask. Instead of having to configure each host separately, network configuration can be handled by a central DHCP server. The length of time that an address can be used can be controlled by means of leases, making effective use of available addresses. If your network is configuring your systems with DHCP, you will not have to configure it. There are different servers for the IPv4 protocol and the IPv6 protocol.

For clarity, the examples in this chapter use the traditional network device name (like eth0 and eth1) instead of the predictable device names (like enp7s0). Keep in mind, that, unless you rename your network devices (see Chapter 2), the actual devices on your system will use a predictable device name (like enp7s0).

IPv6 Stateless Autoconfiguration

In an IPv6 network, the IPv6 protocol includes information that can directly configure a host. With IPv4 you either had to manually configure each host or rely on a DHCP server to provide configuration information. With IPv6, configuration information is integrated into the Internet protocol directly. IPv6 address autoconfiguration is described in detail in RFC 2462.

IPv6 autoconfiguration capabilities are known as stateless, meaning that it can directly configure a host without recourse of an external server. Alternatively, DHCP is stateful, where the host relies on an external DHCP server to provide configuration information. Stateless autoconfiguration has the advantage of hosts not having to rely on a DHCP server to maintain connections to a network. Networks can even become mobile, hooking into one subnet or another, automatically generating addresses as needed. Hosts are no longer tied to a particular DHCP server.

Generating the Local Address

To autoconfigure hosts on a local network, IPv6 makes use of the each network device’s hardware MAC address. This address is used to generate a temporary address, with which the host can be queried and configured.

The MAC address is used to create a link-local address, one with a link-local prefix, FE80::0, followed by an interface identifier. The link-local prefix is used for physically connected hosts such as those on a small local network.

A uniqueness test is then performed on the generated address. Using the Neighbor Discovery Protocol (NDP), other hosts on the network are checked to see if another host is already using the generated link-local address. If no other host is using the address, then the address is assigned for that local network. At this point, the host has only a local address valid within the local physical network. Link-local addresses cannot be routed to a larger network.

Figure 16-1: Stateless IPv6 address autoconfiguration

Generating the Full Address: Router Advertisements

Once the link-local address has been determined, the router for the network is queried for additional configuration information. The information can be either stateful or stateless, or both. For stateless configuration, information such as the network address is provided directly, whereas, for stateful configuration, the host is referred to a DHCP server where it can obtain configuration information. The two can work together. Often the stateless method is used for addresses, and the stateful DHCP server is used to provide other configuration information such as DNS server addresses.

In the case of stateless addresses, the router provides the larger network address, such as the network’s Internet address. This address is then added to the local address, replacing the original link-local prefix, giving either a complete global Internet address or, in the case of private networks, unique-local addresses. Routers will routinely advertise this address information, though it can also be specifically requested. The NDP is used to query the information. Before the address is officially assigned, a duplicate address detection procedure checks to see if the address is already in use. The process depends on the router’s providing the appropriate addressing information in the form of router advertisements. If there is no router, or there are no route advertisements, then a stateful method like DHCP or manual configuration must be used to provide the addresses.

Figure 16-1 shows a network that is configured with stateless address autoconfiguration. Each host first determines its interface identifier using its own MAC hardware address to create a temporary link-local address for each host using the FE80::0 prefix. This allows initial communication with the network's router. The router then uses its network prefix to create full Internet addresses, replacing the link-local prefix.

Figure 16-2: Router renumbering with IPv6 autoconfiguration

Router Renumbering

With IPv6, routers have the ability to renumber the addresses on their networks by changing the network prefix. Renumbering is carried out through the Router Renumbering (RR) Protocol. (See RFC 2894 for a description of router renumbering.) Renumbering is often used when a network changes ISP providers and requires that the net address for all hosts be changed (see Figure 16-2). It can also be used for mobile networks where a network can be plugged into different larger networks, renumbering each time.

With renumbering, routers place a time limit on addresses, similar to the lease time in DHCP, by specifying an expiration limit for the network prefix when the address is generated. To ease the transition, interfaces still keep their old addresses as deprecated addresses, while the new one are first being used. The new ones will be the preferred addresses used for any new connections, while deprecated ones are used for older connections. In effect, a host can have two addresses, one deprecated and one preferred. This regeneration of addresses effectively renumbers the hosts.

DHCP for IPv6 addressing

DHCP provides support for both IPv6 and IPv4 addresses. For IPv6 addresses, the DHCP 4 server is started with the dhcpd6 command. As with IPv6 autoconfiguration, the host identifier for a local address is first automatically generated. This is a local-link address containing a host identifier address generated from the host interface's MAC address.

Once the local-link address is determined, the router is queried for the DHCP server. This information is provided in router advertisements that are broadcast regularly. At this point, the two different kinds of stateful information can be provided by the server: addresses and other configuration information. The host is notified which kinds of stateful information are provided. If address information is not given by the DHCP server, then addresses will be determined using the stateless autoconfiguration method described in the preceding section. If address information is provided, then an address will be obtained from the server instead of being directly generated. Before leasing an address, the server will run a duplicate address detection procedure to make sure the address is unique.

Linux as an IPv6 Router: radvd

For a Linux system that operates as a router, you use the radvd (Router ADVertisement Daemon) to advertise addresses, specifying a network prefix in the /etc/radvd.conf file (Fedora repository). The radvd daemon will detect router network address requests from hosts, known as router solicitations, and provide them with a network address using a router advertisement. These router advertisements will also be broadcast to provide the network address to any hosts that do not send in requests. For radvd to work, you will have to turn on IPv6 forwarding. Use sysctl and set net.ipv6.conf.all.forwarding to 1. To start up the radvd daemon, you use the radvd startup script. To check the router addresses radvd is sending, you can use radvdump.

You will have to configure the radvd daemon yourself, specifying the network address to broadcast. Configuration, though, is very simple, as the full address will be automatically generated using the host’s hardware address. A configuration consists of interface entries, which in turn list interface options, prefix definitions, and options, along with router definitions if needed. The configuration is placed in the /etc/radvd.conf file, which will look something like this:

interface eth0 {
     AdvSendAdvert on;
     prefix fc00:0:0:0::/64
          {
          AdvOnLink on;
          AdvAutonomous on;
          };
};

This assumes one interface is used for the local network, eth0. This interface configuration lists an interface option (AdvSendAdvert) and a prefix definition, along with two prefix options (AdvOnLink and AdvAutonomous). To specify prefix options for a specific prefix, add them within parentheses following the prefix definition. The prefix definition specifies your IPv6 network address. If a local area network has its own network address, you will need to provide its IPv6 network prefix address. For a private network, such as a home network, you can use the unique-local IPv6 prefix, which operates like the IPv4 private network addresses, 192.168.0. The preceding example uses a unique-local address that is used for private IPv6 networks, fc00:0:0:0::, which has a length of 64 bits.

The AdvSendAdvert interface option turns on network address advertising to the hosts. The AdvAutonomous network prefix option provides automatic address configuration, and AdvOnLink simply means that host requests can be received on the specified network interface.

A second network interface is then used to connect the Linux system to an ISP or larger network. If the ISP supports IPv6, this is simply a matter of sending a router solicitation to the ISP router. This automatically generates your Internet address using the hardware address of the network interface that connects to the Internet and the ISP router’s advertised network address. In Figure 16-2, shown earlier, the eth0 network interface connects to the local network, whereas eth1 connects to the Internet.

DHCP

DHCP provides configuration information to systems connected to a TCP/IP network, whether the Internet or an intranet. The machines on the network operate as DHCP clients, obtaining their network configuration information from a DHCP server on their network. A machine on the network runs a DHCP client daemon that automatically receives its network configuration information from its network’s DHCP server. The information includes its IP address, along with the network’s name server, gateway, and proxy addresses, including the netmask. Nothing has to be configured manually on the local system, except to specify the DHCP server it should get its network configuration from. This has the added advantage of centralizing control over network configuration for the different systems on the network. A network administrator can manage the network configurations for all the systems on the network from the DHCP server.

DHCP 4

The DHCP 4 Server provides support for both IPv4 and IPv6 addresses using separate servers. Both are part of the same DCHP package.

A DHCP server also supports several methods for IP address allocation: automatic, dynamic, and manual. Automatic allocation assigns a permanent IP address for a host. Manual allocation assigns an IP address designated by the network administrator. With dynamic allocation, a DHCP server can allocate an IP address to a host on the network only when the host actually needs to use it. Dynamic allocation takes addresses from a pool of IP addresses that hosts can use when needed and release when they are finished.

The DHCP supports the DHCP failover protocol, in which two DHCP servers support the same address pool. Should one fail, the other can continue to provide DHCP services for a network. Both servers are in sync and have the same copy of network support information for each host on the network. Primary and secondary servers in this scheme are designated with the primary and secondary statements.

A variety of DHCP servers and clients are available for different operating systems. The Fedora repository provides DHCP software from the Internet Software Consortium (ISC) at https://www.isc.org/. The software available includes a DHCP server, a client, and a relay agent. The DHCP client is called dhclient, and the DHCP server is called dhcpd (dhclient and dhcp packages).

Configuring DHCP Client Hosts

Configuring hosts to use a DHCP server is a simple matter of setting options for the host’s network interface device, such as an Ethernet card. For a Linux host, you can use a distribution network tool to set the host to automatically access a DHCP server for network information. On a network tool’s tab for configuring the Internet connection, you will normally find a check box for selecting DHCP. Clicking this box will enable DHCP.

Client support is carried out by the dhclient tool. When your network starts up, it uses dhclient to set up your DHCP connection. Though defaults are usually adequate, you can further configure the DHCP client using the /etc/dhclient.conf file. Consult the dhclient.conf Man page for a detailed list of configuration options. dhclient keeps lease information on the DCHP connection in the /var/lib/dhcp/dhclient.leases file. You can also directly run dhclient to configure DHCP connections.

dhclient

Configuring DHCP for IPv4 and IPv6 addressing

The DHCP server package provided a single server, dhcpd, for both IPv4 addressing and for IPv6 addressing. Each form of addressing has a separate configuration file: for IPv4 it is /etc/dhcp/dhcpd.conf, and for IPv6 it is /etc/dhcp/dhcpd6.conf. Documentation for IPv6 configuration is integrated into the man pages for the DHCP server. See the man pages for dhcpd.conf for details on both IPv4 and the IPv6 addressing. The IPv6 sections are labeled DHCP6. The dhcp-options man page lists the DHCP/DHCP6 options. Any server runtime parameter can be set in the corresponding /etc/sysconfig files for the two methods of addressing: /etc/sysconfig.dhcpd and /etc/sysconfig/dhcpd6. Arguments are assigned to the DHCPDARGS variable.

For IPv4 addressing, systemd manages the DHCP server using the dhcpd.service  unit file in the /lib/systemd/system directory. For IPv6 addressing it uses the dhcpd6.service unit file. The DHCP server is started after networking (After) and for the multi-user.target (WantedBy). It is started using the /usr/sbin/dhcpd command which reads configuration from dhcpd.conf. The dhcpd6.service unit file is the same except that the dhcpd command read the dhcpd6.conf file and has the option -6 for IPv6.

dhcpd.service

[Unit]
Description=DHCPv4 Server Daemon
Documentation=man:dhcpd(8) man:dhcpd.conf(5)
Wants=network-online.target
After=network-online.target
After=time-sync.target

[Service]
Type=notify
EnvironmentFile=-/etc/sysconfig/dhcpd
ExecStart=/usr/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid $DHCPDARGS
StandardError=null
[Install]
WantedBy=multi-user.target

Use the systemctl command with the dhcpd or dhcpd6 command with the start, restart, and stop options to manage the server. The following examples start the dhcp server with either IPv4 or IPv6 addressing. Use the stop option to shut it down and restart to restart them.

sudo systemctl start dhcpd
sudo systemctl start dhcpd6

Dynamically allocated IP addresses, known as leases, will be assigned for a given time. When a lease expires, it can be extended or a new one generated. Current leases are listed in the dhcpd.leases file (dhcpd6.leases for the IPv6 addressing) located in the /var/lib/dhcpd directory. A lease entry will specify the IP address and the start and end times of the lease along with the client's hostname.

DHCP 4 IPv4 server configuration: /etc/dhcp/dhcpd.conf

The configuration file for the IPv4 addressing for the dhcpd server is /etc/dhcp/dhcpd.conf. A sample configuration file named dhcpd.conf.sample is located in the /usr/share/doc directory for the dhcp server. There is also a configuration file for the IPv6 addressing, dhcpd6.conf.sample. On the command line or terminal window, you can use the following command to move to the DHCP documentation directory.

cd /usr/share/doc/dhcp*

In the configuration file, you specify parameters and declarations that define how different DHCP clients on your network are accessed by the DHCP server, along with options that define information passed to the clients by the DHCP server. These parameters, declarations, and options can be defined globally for certain subnetworks or for specific hosts. Global parameters, declarations, and options apply to all clients unless overridden by corresponding declarations and options in subnet or host declarations. Technically, all entries in a dhcpd.conf file are statements that can be either declarations or parameters. All statements end with a semicolon. Options are specified in options parameter statements. Parameters differ from declarations in that they define if and how to perform tasks, such as how long a lease is allocated. Declarations describe network features such as the range of addresses to allocate or the networks that are accessible. See Table 16-1 for a listing of commonly used declarations and options.

Declarations provide information for the DHCP server or designate actions it is to perform. For example, the range declaration is used to specify the range of IP addresses to be dynamically allocated to hosts:

range 192.168.0.5 192.168.0.128;

With parameters, you can specify how the server is to treat clients. For example, the default-lease-time declaration sets the number of seconds a lease is assigned to a client. The filename declaration specifies the boot file to be used by the client. The server-name declaration informs the client of the host from which it is booting. The fixed-address declaration can be used to assign a static IP address to a client. See the Man page for dhcpd.conf for a complete listing.

Entries

Description

Declarations

shared-network name

Indicates if some subnets share the same physical network.

subnet subnet-number netmask

References an entire subnet of addresses.

range [ dynamic-bootp ] low-address [ high-address];

Provides the highest and lowest dynamically allocated IP addresses.

host hostname

References a particular host.

group

Lets you label a group of parameters and declarations and then use the label to apply them to subnets and hosts.

allow unknown-clients;
deny unknown-clients;

Does not dynamically assign addresses to unknown clients.

allow bootp; deny bootp;

Determines whether to respond to bootp queries.

allow booting; deny booting;

Determines whether to respond to client queries.

Parameters

default-lease-time time;

Assigns length in seconds to a lease.

max-lease-time time;

Assigns maximum length of lease.

hardware hardware-type hardware-address;

Specifies network hardware type (Ethernet or token ring) and address.

server-name "name";

Specifies name of the server from which a client is booting.

next-server server-name;

Specifies server that loads the initial boot file specified in the filename.

fixed-address address [, address ... ];

Assigns a fixed address to a client.

get-lease-hostnames flag;

Determines whether to look up and use IP addresses of clients.

authoritative;
not authoritative;

Denies invalid address requests.

server-identifier hostname;

Specifies the server.

Options

option subnet-mask ip-address;

Specifies client’s subnet mask.

option routers ip-address [, ip-address... ];

Specifies list of router IP addresses on client’s subnet.

option domain-name-servers ip-address [, ip-address... ];

Specifies list of domain name servers used by the client.

option log-servers ip-address [, ip-address... ];

Specifies list of log servers used by the client.

option host-name string;

Specifies client’s hostname.

option domain-name string;

Specifies client’s domain name.

option broadcast-address ip-address;

Specifies client’s broadcast address.

option nis-domain string;

Specifies client’s Network Information Service domain.

option nis-servers ip-address [, ip-address... ];

Specifies NIS servers the client can use.

option smtp-server ip-address [, ip-address... ];

Lists SMTP servers used by the client.

option pop-server ip-address [, ip-address... ];

Lists POP servers used by the client.

option www-server ip-address [, ip-address... ];

Lists web servers used by the client.

 Table 16-1: DHCP Declarations, Parameters, and Options

Options provide information to clients that they may need to access network services, such as the domain name of the network, the domain name servers that clients use, or the broadcast address. See the Man page for dhcp-options for a complete listing. This information is provided by option parameters as shown here:

option broadcast-address 192.168.0.255;
option domain-name-servers 192.168.0.1, 192.168.0.4;
option domain-name "mytrek.com";

Your dhcpd.conf file will usually begin with declarations, parameters, and options that you define for your network serviced by the DHCP server. The following example provides router (gateway), netmask, domain name, and DNS server information to clients. Additional parameters define the default and maximum lease times for dynamically allocated IP addresses.

option routers 192.168.0.1;
option subnet-mask 255.255.255.0;
option domain-name "mytrek.com ";
option domain-name-servers 192.168.0.1;
default-lease-time 600;
max-lease-time 7200;

With the subnet, host, and group declarations, you can reference clients in a specific network, particular clients, or different groupings of clients across networks. Within these declarations, you can enter parameters, declarations, or options that will apply only to those clients. Scoped declarations, parameters, and options are enclosed in braces. For example, to define a declaration for a particular host, you use the host declaration as shown here:

host rabbit {
        declarations, parameters, or options;
        }

You can collect different subnet, global, and host declaration into groups using the group declaration. In this case, the global declarations are applied only to those subnets and hosts declared within the group.

Dynamic IPv4 Addresses for DHCP 4

Your DHCP server can be configured to select IP addresses from a given range and assign them to different clients. Given a situation where you have many clients that may not always be connected to the network, you can effectively service them with a smaller pool of IP addresses. IP addresses are assigned only when they are needed. With the range declaration, you specify a range of addresses that can be dynamically allocated to clients. The declaration takes two arguments, the first and last addresses in the range.

range 192.168.1.5 192.168.1.128;

For example, if you are setting up your own small home network, you would use a network address beginning with 192.168. The range would specify possible IP addresses with that network. So, for a network with the address 192.168.0.0, you place a range declaration along with any other information you want to give to your client hosts. In the following example, a range of IP addresses extending from 192.168.0.1 to 192.168.0.128 can be allocated to the hosts on that network:

range 192.168.0.5 192.168.0.128;

You should also define your lease times, both a default and a maximum:

default-lease-time 600;
max-lease-time 7200;

For a small, simple home network, you just need to list the range declaration along with any global options as shown here. If your DHCP server is managing several subnetworks, you will have to use the subnet declarations.

In order to assign dynamic addresses to a network, the DHCP server will require that your network topology be mapped. This means it needs to know what network addresses belong to a given network. Even if you use only one network, you will need to specify the address space for it. You define a network with the subnet declaration. Within this subnet declaration, you can specify any parameters, declarations, or options to use for that network. The subnet declaration informs the DHCP server of the possible IP addresses encompassed by a given subnet. This is determined by the network IP address and the netmask for that network. The next example defines a local network with address spaces from 192.168.0.0 to 192.168.0.255. The range declaration allows addresses to be allocated from 192.168.0.5 to 192.168.0.128.

subnet 192.168.1.0 netmask 255.255.255.0 {
          range 192.168.0.5 192.168.0.128;
}

Versions of DHCP prior to 3.0 required that you even map connected network interfaces that are not being served by DHCP. Thus each network interface has to have a corresponding subnet declaration. Those not being serviced by DHCP don’t have a not authoritative parameter as shown here (192.168.2.0 being a network not to be serviced by DHCP). In version 3.0 and later, DHCP simply ignores unmapped network interfaces:

subnet 192.168.2.0 netmask 255.255.255.0 {
      not authoritative;
}

The implementation of a very simple DHCP server for dynamic addresses is shown in the sample dhcpd.conf file that follows:

/etc/dhcp/dhcpd.conf

option routers 192.168.0.1;
option subnet-mask 255.255.255.0;
option domain-name "mytrek.com ";
option domain-name-servers 192.168.0.1;

subnet 192.168.1.0 netmask 255.255.255.0 {
         range 192.168.0.5 192.168.0.128;
         default-lease-time 21600;
         max-lease-time 43200;
         }

DHCP 4 IPv6 Server Configuration

The DHCP IPv6 addressing configuration file is /etc/dhcp/dhcpd6.conf file.  IPv6 addressing (DHCP6) documentation is integrated into the DHCP man pages (dhcpd, dhcpd.conf, and dhcp-options). Check the dhcpd6.conf.sample file in /usr/share/doc/dhcp*. The IPv6 configuration is similar to the IPv4 configuration. Certain options are the same such as the default-lease-time. Global settings will have a dhcp6 qualifier, such as dhcp6.name-servers and dhcp6.preference for the domain servers (see the dhcp-options man page for details). The server lease file is set by dhcpv6-lease-file-name.

dhcpv6-lease-file-name "/var/lib/dhcpd/dhcpd6.leases"

The subnet declaration is similar to the IPv4 configuration but uses the subnet6 and range6 commands along with IPv6 addresses. The subnet6 declaration specifies a network identifier using CIDR notation, the IPv6 address prefix and bit mask.

subnet6 3ffe:501:ffff:100::/64 {

The range6 statement specifies available addresses, using an address for the upper limit of the range and one for the lower limit, or using CIDR notation to specify the set of addresses.

range6 3ffe:501:ffff:100::10 3ffe:501:ffff:100::20;

As a security alternative, addresses can be randomly generated for temporary use (RFC 4941).  Add the temporary qualifier to the range6 option, using the entire prefix for temporary addresses. 

range6 3ffe:501:ffff:100:: temporary;

The following example is based on the sample dhcpd6.conf file, defining a subnet range.

subnet6 3ffe:501:ffff:100::/64 {
             range6 3ffe:501:ffff:100::10 3ffe:501:ffff:100::11;
             }

You can also assign IPVv6 address prefixes. The prefix6 statement delegates IPv6 prefixes (RFC 3633), specifying an address range for IPv6 prefixes (a high and low address for the range). 

prefix6 3ffe:501:ffff:100:: 3ffe:501:ffff:111:: /64

For clients that have fixed addresses, you use the host declaration and the fixed-address6 statement. The host-identifier statement uses options to identify the host, such as dhcpd6.client-id which specifies the client's DHCP unique identifier (DUID). A DUID is a permanent identifier based on the network device's hardware link-layer address (duid-llt and duid-ll) or an identifier provided by the vendor (duid-en), see RFC 3315 for more details.

host myclient {
         host-identifier option dhcp6.client-id 00:01:00:01:00:04:93:e0:00:00:00:00:a2:a2;
         fixed-address6 3ffe:501:ffff:100::1234;
         }

DHCP 4 Dynamic DNS Updates

For networks that also support a Domain Name Server, dynamic allocation of IP addresses currently needs to address one major constraint: DHCP needs to sync with a DNS server. A DNS server associates hostnames with particular IP addresses, whereas in the case of dynamic allocation, the DHCP server randomly assigns its own IP addresses to different hosts. These may or may not be the same as the IP addresses that the DNS server expects to associate with a hostname. A solution to this problem is being developed, called Dynamic DNS. With Dynamic DNS, the DHCP server is able to automatically update the DNS server with the IP addresses the DHCP server has assigned to different hosts.

Note: Alternatively, if you want to statically synchronize your DHCP and DNS servers with fixed addresses, you configure DHCP to assign those fixed addresses to hosts. You can then have the DHCP server perform a DNS lookup to obtain the IP address it should assign, or you can manually assign the same IP address in the DHCP configuration file. Performing a DNS lookup has the advantage of specifying the IP address in one place, the DNS server.

The DHCP server has the ability to dynamically update BIND DNS server zone configuration files. You enable dynamic updates on a DNS server for a zone file by specifying the allow-update option for it in the named.conf file. Furthermore, it is strongly encouraged that you use TSIG signature keys to reference and authenticate the BIND and DHCP servers. Currently, DHCP uses the Interim DNS Update Scheme to perform dynamic DNS updates, replacing an earlier Ad-Hoc DNS Update Scheme. A finalized version will be implemented in future DHCP releases. You can find detailed information about dynamic DNS in the dhcpd.conf Man page.

Enabling the use of a TSIG key involves syncing configurations for both your DHCP and DNS servers. Both have to be configured to use the same key for the same domains. First, you need to create a shared secret TSIG signature key using dnssec-keygen, In the DNS server, you place TSIG key declarations and allow-update entries in the server's named.conf file, as shown in this example:

key mydhcpserver {
algorithm HMAC-MD5;
secret "ONQAfbBLnvWU9H8hRqq/WA==";
};

zone "mytrek.com" {
       type master;
       file "mytrek.com";
       allow-update {key mydhcpserver;};
};

zone "1.168.192.in-addr.arpa" {
       type master;
       file "192.168.0";
       allow-update {key mydhcpserver;};
};

In the DHCP server, you place a corresponding TSIG key declaration and allow-update entries in the server’s dhcpd.conf file, as shown in this example. The key declaration has the same syntax as the DNS server. DHCP zone statements are then used to specify the IP address of the domain and the TSIG key to use.

key mydhcpserver {
    algorithm HMAC-MD5;
    secret "ONQAfbBLnvWU9H8hRqq/WA==";
    };

zone mytrek.com. {                #DNS domain zone to update
       primary 192.168.0.1;       #address of DNS server
       key mydhcpserver;         #TSIG signature key
};

zone 1.168.192.in-addr.arpa. {    #domain PTR zone to update
       primary 192.168.0.1;       #address of DNS server
       key mydhcpserver;          # TSIG signature key
};

The domain names and IP addresses need to match exactly in the configuration files for both the DNS and DHCP servers. Unlike in the named.conf file, there are no quotes around the domain name or IP addresses in the dhcpd.conf file. In the dhcpd.conf file, the domain names and IP addresses used in the zone statement also need to end with a period, as they do in the DNS zone files. The key statement lists the key to use. Though the DHCP server will try to determine the DNS servers to update, it is recommended that you explicitly identify them with a primary statement in a zone entry.

To generate a fully qualified hostname to use in a DNS update, the DHCP server will normally use its own domain name and the hostname provided by a DHCP client (see the dhcpd.conf Man page for exceptions). Should you want to assign a specific hostname to a host, you can use the ddns-hostname statement to specify it in the host’s hardware section. The domain name is specified in the domain-name option:

option domain-name "mytrek.com"

The DNS update capability can be turned on or off for all domains with the ddns-update-style statement. It is on by default. To turn off DNS updates for particular domains, you can use the ddns-updates statement. This is also on by default.

DHCP 4 IPv4 Subnetworks

If you are dividing your network space into several subnetworks, you can use a single DHCP server to manage them. In that case, you will have a subnet declaration for each subnetwork. If you are setting up your own small network, you use a network address beginning with 192.168. The range specifies possible IP addresses within that network so, for a network with the address 192.168.0.0, you create a subnet declaration with the netmask 255.255.255.0. Within this declaration, you place a range declaration along with any other information you want to give to your client hosts. In the following example, a range of IP addresses extending from 192.168.0.1 to 192.168.0.75 can be allocated to the hosts on that network:

subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.5 192.168.0.75;
}

You may want to specify different policies for each subnetwork, such as different lease times. Any entries in a subnet declaration will override global settings. So if you already have a global lease time set, a lease setting in a subnet declaration will override it for that subnet. The next example sets different lease times for different subnets, as well as different address allocations. The lease times for the first subnet are taken from the global lease time settings, whereas the second subnet defines its own lease times:

default-lease-time 21600;
max-lease-time 43200;

subnet 192.168.1.0 netmask 255.255.255.0 {
      range 192.168.0.5 192.168.0.75;
      }
subnet 192.168.1.128 netmask 255.255.255.252 {
      range 192.168.0.129 192.168.0.215;
      default-lease-time 56000;
      max-lease-time 62000;
       }

If your subnetworks are part of the same physical network, you need to inform the server of this fact by declaring them as shared networks. You do this by placing subnet declarations within a shared-network declaration, specifying the shared network’s name. The name can be any descriptive name, though you can use the domain name. Any options specified within the shared-network declaration and outside the subnet declarations will be global to those subnets. In the next example, the subnets are part of the same physical network and so are placed within a shared-network declaration:

shared-network mytrek.com
{
default-lease-time 21600;
max-lease-time 43200;
subnet 192.168.1.0 netmask 255.255.255.0 {
        range 192.168.0.5 192.168.0.75;
        }
subnet 192.168.1.128 netmask 255.255.255.252 {
        range 192.168.0.129 192.168.0.215;
        default-lease-time 56000;
        max-lease-time 62000;
        }
}

DHCP 4 IPv4 Fixed Addresses

Instead of using a pool of possible IP addresses for your hosts, you may want to give each one a specific address. Using the DHCP server still gives you control over which address will be assigned to a given host. However, to assign an address to a particular host, you need to know the hardware address for that host’s network interface card (NIC). In effect, you have to inform the DHCP server that it has to associate a particular network connection device with a specified IP address. To do that, the DHCP server needs to know which network device you are referring to. You can identify a network device by its hardware address, known as its MAC address. To find out a client’s hardware address, you log in to the client and use the ifconfig command to find out information about your network devices. To list all network devices, use the -a option. If you know your network device name, you can use that. The next example will list all information about the first Ethernet device, eth0:

ifconfig eth0

This will list information on all the client’s network connection devices. The entry (usually the first) with the term HWaddr will display the MAC address. Once you have the MAC address, you can use it on the DHCP server to assign a specific IP address to that device.

In the dhcpd.conf file, you use a host declaration to set up a fixed address for a client. Within the host declaration, you place a hardware option in which you list the type of network connection device and its MAC address. Then you use the fixed-address parameter to specify the IP address to be assigned to that device. In the following example, the client’s network device with a MAC address of 08:00:2b:4c:29:32 is given the IP address 192.168.0.2:

host rabbit {
             option host-name "rabbit.mytrek.com"
             hardware ethernet 08:00:2b:4c:29:32;
             fixed-address 192.168.0.2;
             }

You can also have the DHCP server perform a DNS lookup to obtain the host’s IP address. This has the advantage of letting you manage IP addresses in only one place, the DNS server. Of course, this requires that the DNS server is operating so that the DHCP server can determine the IP address. For example, a proxy server connection (which can provide direct web access) needs just an IP address, not a DNS hostname, to operate. If the DNS server were down, the preceding example would still assign an IP address to the host, whereas the following example would not:

host rabbit {
             option host-name "rabbit.mytrek.com"
             hardware ethernet 08:00:2b:4c:29:32;
             fixed-address rabbit.mytrek.com;
             }

You can also use the host declaration to define network information for a diskless workstation or terminal. In this case, you add a filename parameter specifying the boot file to use for that workstation or terminal. Here the terminal called myterm obtains boot information from the server turtle.mytrek.com:

host myterm {
             option host-name "myterm.mytrek.com"
             filename "/boot/vmlinuz";
             hardware ethernet 08:00:2b:4c:29:32;
             server-name "turtle.mytrek.com";
             }

A common candidate for a fixed address is the DNS server for a network. Usually, you want the DNS server located at the same IP address, so that it can be directly accessed. The DHCP server can then provide this IP address to its clients.

Part 5:  Administration Topics

17. Basic System Administration

18. Shell Configuration

19. Administering TCP/IP Networks

17. Basic System Administration

Linux is designed to serve many users at the same time, providing an interface between the users and the system with its resources, services, and devices. Users have their own shells through which they interact with the operating system, but you may need to configure the operating system itself in different ways such as adding new users, managing devices like printers and scanners, and accessing file systems. Such operations come under the heading of system administration. The person who performs such actions is referred to as either a system administrator or a superuser. In this sense, there are two types of interaction with Linux: regular users' interactions, and those of the superuser, who performs system administration tasks. The chapters in this section cover operations such as changing system runlevels, managing users, installing software, and compiling the kernel. You perform most of these tasks only rarely, such as adding a new printer or mounting a file system. For  detailed documentation and configuration of System Administration tasks on Fedora see the Fedora System Administration Guide.

https://docs.fedoraproject.org/f28/system-administrators-guide/index.html

Fedora Administration Tools

On Fedora, most administration tasks can be handled by a set of separate specialized administrative tools developed and supported by Red Hat, Fedora, and GNOME such as those for user management and printer configuration. Most of these are desktop-based and will work on GNOME. You can access the GNOME desktop-based tools as any user from the System Settings from the user menu. Here you will find tools to set the time and date, manage users, and configure printers. User Accounts lets you create and edit users. Printers lets you install and reconfigure printers. All tools provide very intuitive desktop interfaces that are easy to use. Tools are identified by simple descriptive terms. In addition, you can use older administrative tools that begin with the term system-config. For example, the printer configuration tool is listed as Printing, but its actual name is system-config-printer. You can separately invoke any tool by entering its name in a terminal window. Table 17-1 provides a listing of Fedora administration tools.

Fedora Administration Tool

Description

system-config-users

User and Group configuration tool

GNOME users

User configuration tool

system-config-printer

Printer configuration tool

system-config-rootpassword

Changes the root user password

system-config-selinux

Manage and configure SELinux

Network Manager

Automates wireless and standard network connections.

cockpit

Starts and stops servers, as well as enables and disables them.

firewall-config

Sets up a network firewall for FirewallD.

system-config-firewall

Sets up a network firewall for iptables.

system-config-httpd

Configures an Apache Web server.

Table 17-1: Fedora Configuration Tools

System Directories

Your Linux file system is organized into directories whose files are used for different system functions (see Table 17-2). For basic system administration, you should be familiar with the system program directories where applications are kept, the system configuration directory (/etc) where most configuration files are placed, and the system log directory (/var/log) that holds the system logs, recording activity on your system. Other system directories are covered in their respective chapters.

Directories

Description

/bin

System-related programs

/sbin

System programs

/usr/sbin

System programs for user related tasks

/lib

System and application libraries

/etc

Configuration files for system and network services and applications

/home

The location of user home directories and server data directories, such as Web and FTP site files

/run/media

The location where removable disks and media are mounted (DVDs, USB drive)

/var

The location of system directories whose files continually change, such as logs, printer spool files, and lock files

/usr

User-related programs and files. Includes several key subdirectories, such as /usr/bin, /usr/X11, and /usr/doc

/usr/bin

Programs for users

/dev

Dynamically generated directory for device files

/etc/X11

X Window System configuration files

/usr/share

Shared files

/usr/share/doc

Documentation for applications

/tmp

Directory for system temporary files

/var/log

Logging directory

Table 17-2: System Directories

Program Directories

Directories with “bin” in the name are used to hold programs. The /bin directory holds basic user programs, such as login shells (BASH, TCSH, and ZSH) and file commands (cp, mv, rm, ln, and so on). The /sbin directory holds specialized system programs for such tasks as file system management (fsck, fdisk, mkfs) and system operations like shutdown and startup (init). The /usr/bin directory holds program files designed for user tasks. The /usr/sbin directory holds user-related system operations, such as useradd to add new users. The /lib directory holds all the libraries your system makes use of, including the main Linux library, libc, and subdirectories such as modules, which holds all the current kernel modules.

Configuration Directories and Files

When you configure different elements of your system, like users, applications, servers, or network connections, you make use of configuration files kept in certain system directories. Configuration files are placed in the /etc directory, with more specific device and service configuration located in the /etc/sysconfig directory.

Configuration Files: /etc

The /etc directory holds your system, network, server, and application configuration files. Here you can find the fstab file listing your file systems, the hosts file with IP addresses for hosts on your system, and /etc/default/grub for the GRUB boot loader options. This directory includes various subdirectories, such as /etc/httpd for the Apache Web server configuration files, /etc/X11 for the X Window System and window manager configuration files, and /etc/udev for rules to generate device files in /dev. You can configure many applications and services by directly editing their configuration files, though it is best to use a corresponding administration tool. Table 17-3 lists several commonly used configuration files found in the /etc directory.

/etc/sysconfig

On Red Hat and Fedora systems, configuration and startup information is also kept in the /etc/sysconfig directory. Here you will find files containing definitions of runtime options for services such as the Web server or the IPtables firewall. These entries were defined for you when you installed the service software.

Several device and system files have been removed from /etc/sysconfig, and have been replaced by configuration files in the /etc directory. The /etc/sysconfig's keyboard, clock, and i18n files have been deprecated. Device configuration for your keyboard has been moved from /etc/sysconfig/keyboard to /etc/vconsole.conf. The time zone information is implemented as the link /etc/localtime to the appropriate time zone file. Language settings are specified in /etc/locale.conf.

System Logs, journals, and journald

Various system logs for tasks performed on your system are stored and managed by the journald logging daemon. In effect, logs are now considered to be journals accessible by a systemd daemon, journald. From the command line (terminal window), you can use the journalctl command to access messages. The -f option displays the last few messages and is equivalent to displaying the last few messages in the old /var/log/messages file. The following command lists the last few messages:

journalctl -f

To see logs from the last system startup (boot), you use the -b option.

File

Description

/etc/bashrc

Default shell configuration file Bash shell

/etc/group

Contains a list of groups with configurations for each

/etc/fstab

Automatically mounts file systems when you start your system

/boot/grub/

The GRUB configuration files for the GRUB boot loader.

/etc/profile

Default shell configuration file for users

/etc/mtab

Currently mounted file systems

/etc/passwd

Contains user password and login configurations

/etc/services

Services run on the system and the ports they use

/etc/shadow

Contains user-encrypted passwords

/etc/shells

Shells installed on the system that users can use

/etc/sudoers

Sudo configuration to control administrative access

Directories

/etc/cron

Cron scripts

/etc/cups

CUPS printer configuration files

/etc/systemd/system

systemd unit files, modifiable

/lib/systemd/system

systemd unit files

/etc/modprobe.d

Directory with kernel module configuration files

/etc/openldap

Configuration for Open LDAP server

/etc/skel

Directory that holds the versions of initialization files, such as .bash_profile, which are copied to new users’ home directories

/etc/sysconfig

Red Hat and Fedora service configuration environments

/etc/terminfo

Contains terminal type specifications for terminals that could be connected to the system

/etc/X11

X Window System configuration files

/etc/xinetd.d

Configuration scripts for services managed by Xinetd server (deprecated)

/etc/udev

Rules for generating devices

Table 17-3: Configuration Files and Directories

journalctl -b

To see messages for a particular service, you use the -u option and the name of the unit’s service file, such as smb.service. The following lists the messages for the samba server.

journalctl -u smb.service

With the --since and --until options, you can further specify a time.

journalctl -u smb.service --since=12:00

If you want, you can still install and run the older rsyslogd, which stores message in the /var/log/messages file.

To view these logs you can use GNOME Logs, Utilities | Logs (GNOME Logs on GNOME Software or the gnome-logs package on Packages) . A sidebar lists different log categories: Important, All, Applications, System, Security, and Hardware. Selecting one displays the log in the right pane (see Figure 17-1). A search button on the top right opens a search box, in which you can search for messages in the selected log, modifying the search by field and time. A save button on the top right lets you save the logs to a file. Logs queries the journald daemon for log reports using journalctl.

Figure 17-1: GNOME Logs

Performance Analysis Tools and Processes

Linux treats each task performed on your system as a process, which is assigned a number and a name. You can examine these processes as well as start and stop them. Fedora provides several tools for examining processes as well as your system performance (see Table 17-4).

Performance Tool

Description

glances

Comprehensive system and network monitoring

vmstat

Performance of system components

top

Listing of most CPU-intensive processes

free

Listing of free RAM memory

sar

System activity information

iostat

Disk usage

GNOME System Monitor

System monitor for processes and usage monitoring (System | Administration | System Monitor)

KDE System Monitor

KDE system monitor for processes and usage monitoring

Frysk

Monitoring tool for system processes

Table 17-4: Performance Tools

Glances

Glances is a comprehensive system monitoring tool run from the command line in a terminal window with the glances command. It shows detailed resource use for the system, network, disk, file system, sensors, and processes. It also warns you of any critical alerts. The system section covers detailed memory, CPU, swap and load usage. The network section shows the activity on each network device. The Disk I/O section lists your storage devices and their read/write usage. The File Sys section shows al your partitions and how much memory is used. The Sensors section shows the temperature detected by your sensors such as those for CPU, GPU, and the ambient temperature. The Tasks section lists your active processes by CPU usage, showing memory used, pid, user and the command. Press q to end your glances session.

Glances is organized into modules which you can disable to show only a limited set of reports. For example, if you are not interested in the disk I/O reports, you can disable the diskio module with the --disable-diskio option. See the glances man page for a complete list of module options you can use.

glances -- disable-diskio.

There are also several runtime commands you can use to show and hide modules, such as f to toggle the file system reports on an off, d to toggle disk I/O, n for network stats, s for showing sensors, and p to sort processes by name.

vmstat, free, top, iostat, dstat, and Xload

From a terminal window, you can use tools such as vmstat, free, top, and iostat to monitor your system (systat package). The vmstat command outputs a detailed listing indicating the performance of different system components, including CPU, memory, I/O, and swap operations. A report is issued as a line with fields for the different components. If you provide a time period as an argument, it repeats at the specified interval, usually a few seconds. The top command provides a listing of the processes on your system that are the most CPU intensive, showing what processes are using most of your resources. The listing is in real time and updated every few seconds. Commands are provided for changing a process’s status, such as its priority.

The free command lists the amount of free RAM memory on your system, showing how much is used and how much is free, as well as what is used for buffers and swap memory. Xload is an X Window System tool showing the load, CPU, and memory, iostat displays your disk usage, and sar shows system activity information.

Frysk

Frysk is a specialized complex monitoring tool for system processes. With Frysk you can set up very specific monitoring tasks, focusing on particular applications and selecting from a set of observer processes to provide information about exit notification, system calls, and execution. You can also create your own customized observers for processes. Find out more about Frysk at http://sourceware.org/frysk.

GNOME System Monitor

On the GNOME desktop (Fedora Workstation, the GNOME System Monitor displays system information and monitors system processes (Utilities | System Monitor). It has three tabs: Processes, Resources, and File Systems. The Resources tab displays graphs for CPU History, Memory and Swap History, and Network History. If your system has a multi-core CPU, the CPU History graph shows the usage for each CPU. The Memory and Swap Memory graph shows the amount of memory in use. The Network History graph displays both the amount of sent and received data, along with totals for the current session.

The File Systems tab lists your file systems, including where they are mounted, their type, and the amount of disk space used and how much is free. You can sort the list by any category. Device, directory, and type names are listed alphabetically. Total, free, available, and used space can be sorted numerically in ascending or descending order. Double clicking on a file system entry will open that file system in a file manager window.

The Processes tab lists your processes, letting you sort and search processes. You can use field buttons to sort by name (Process Name), process ID (ID), percentage of use (%CPU), and memory used (Memory), among others. The menu (right side of the menu bar) lets you select all processes, just your own (My Processes), or active processes. You can stop any process by selecting it and then clicking the End Process button (lower-right corner) or by right-clicking on it and choosing End. You can right-click a process entry to display a menu with actions you can take on the selected process, such as stopping (Stop), ending (End), killing (Kill), and continuing a process (Continue), as well as changing the priority of the process (Change Priority). The Open Files entry opens a dialog listing all the files, sockets, and pipes the process is using. The Properties entry displays a dialog showing all the details of a process, such as the name, user, status, memory use, CPU use, and priority. Memory Maps display, selected from the Memory Maps entry, shows information on virtual memory, inodes, and flags for a selected process. 

Display features such as the colors used for CPU graphs can be set using the dconf editor's gnome-system-monitor keys at org | gnome | gnome-system-monitor.

Ending Processes

You can use the pkill command with a process name or a process ID to end a process. To use a process name, enter the process name with the -n option for the most recent process for that name.

pkill -n firefox

You can also use the kill command in a terminal window to end a process. The kill command takes as its argument a process ID. Be sure you obtain the correct one. Entering the incorrect process ID could also cripple your system. Use the ps command to display a process ID. You can search for a process using the -C option  or the -aux options. The ps command with the -C option searches for a particular application name. The -o pid= option displays only the process ID, instead of the process ID, time, application name, and tty. Once you have the process ID, you can use the kill command, with the process ID as its argument, to end the process.

$ ps -C firefox -o pid=
5555
$ kill 5555

One way to ensure the correct number is to use the ps command to return the process number directly as an argument to a kill command. The process is then stopped by first executing the ps command to obtain the process ID for the firefox process (back quotes), and then using that process ID in the kill command to end the process. The -o pid= option displays only the process ID.

kill `ps -C firefox -o pid=`

To search for a process using a pattern, you can use a ps command with the -aux option to list all processes and pipe the output to a grep command with a specified pattern. The following command lists all X Window System processes:

ps -aux | grep 'firefox'

You can obtain just the process IDs with the pidof command.

pidof  firefox

On the desktop, should you have to force a process or application to quit, you can use the GNOME System Monitor Processes tab to find, select, and stop it. You should be sure of the process you want to stop. Ending a critical process could cripple your system.

Application processes will bear the name of the application, and you can use those to force an application to quit. Ending processes manually is usually preformed for open-ended operations that you are unable to stop normally. Clicking on the button at the lower left displays the properties for a selected process. The menu button on the upper right shows display options such as active, all, your processes, and processes arranged in expandable trees showing their dependencies. The search button, also on the upper right, opens a search box letting you search for a process. 

Scheduling Tasks: systemd.timers and cron

Scheduling regular maintenance tasks, such as backups, can be managed either by using the systemd timers or by the cron service. The systemd timers are systemd files that run service files. Check the man page for systemd.timers for a detailed description of timers. They have the extension .timer. A timer file will automatically run a corresponding service file that has the same name. For example, the dnf-automatic.timer will run the dnf-automatic.service file. The timer file only contains scheduling information. Its filename determines which service file to run.  It is possible to designate a different service file with the Unit directive in the timer file. If you want to run a command line operation for which there is no service file, you can create your own with an ExecStart entry for that command.

The timer files have a timer section in which you define when the service file is run. There are options that are relative to certain starting points like when system booted up, and the OnCalendar option that that reference calendar dates. The OnCalendar option uses calendar event expressions as defined on the systemd.time man page. A calendar even expression consists of a weekday, year, month, and time. The time is specified in hour, minute, and second, separated by colons. A range of weekdays is separated by two periods, and specific weekdays by commas. Leaving out the year or month selects any year or month. The following references weekdays in May at 2 pm.

OnCalendar=Mon..Fri 05 14:00

You can create timer files and place them in the /etc/systemd/system directory. If you also have to set up a service file for it, you can place it in the same directory. To activate a timer be sure to enable it with systemctl. If you created a service file, be sure to enable that also.

You can still use the older cron service to schedule tasks. The cron service is implemented by the cron daemon that constantly checks for certain actions to take. These tasks are listed in the crontab file. The cron daemon constantly checks the user’s crontab file to see if it is time to take these actions. Any user can set up a crontab file. The root user can set up a crontab file to take system administrative actions, such as backing up files at a certain time each week or month. The name of the cron daemon is crond.

You can also start and stop the crond service manually, which you may want to do for emergency maintenance or during upgrades. Use the systemctl command and the stop option to shut down the service, and the start option to run it again, and restart to restart it:

sudo systemctl stop crond

Cron task schedules are kept in crontab files, like /etc/crontab. An entry has six fields: the first five are used to specify the time for an action, while the last field is the action itself. The first field specifies minutes (0–59), the second field specifies the hour (0–23), the third field specifies the day of the month (1–31), the fourth field specifies the month of the year (1–12, or month prefixes like Jan and Sep), and the fifth field specifies the day of the week (0–6, or day prefixes like Wed and Fri), starting with 0 as Sunday. In each of the time fields, you can specify a range, a set of values, or use the asterisk to indicate all values. For example, 1-5 for the day-of-week field specifies Monday through Friday. In the hour field, 8, 12, 17 would specify 8 a.m., 12 noon, and 5 p.m. An * in the month-of-year field indicates every month. The format of a cron field follows:

minute  hour  day-month  month  day(s)-week  task

The following example backs up the projects directory at 2:00 a.m. every weekday:

0 2 * * 1-5   tar cf /home/backp /home/projects

The same entry is listed here again using prefixes for the month and weekday:

0 2 * * Mon-Fri tar cf /home/backp /home/projects

To specify particular months, days, weeks, or hours, you can list them individually, separated by commas. For example, to perform the previous task on Sunday, Wednesday, and Friday, you could use 0,3,5 in the day-of-week field, or their prefix equivalents, Sun,Wed,Fri.

0 2 * * 0,3,5   tar cf /home/backp /home/projects

Cron also supports comments. A comment is any line beginning with a # sign.

# Weekly backup for Chris's projects
0 2 * * Mon-Fri  tar cf /home/backp /home/projects

The cron service also lets you define environment variables for use with tasks performed. Fedora defines variables for SHELL, PATH, HOME, and MAILTO. SHELL designates the shell to use tasks, in this case, the bash shell. PATH lists the directories where programs and scripts can be found. This example lists the standard directories, /usr/bin and /bin, as well as the system directories reserved for system applications, /usr/sbin and /sbin. MAILTO designates to who the results of a task are to be mailed. By default, these are mailed to the user who schedules it, but you can have the results sent to a specific user, such as the administrator's e-mail address, or an account on another system in a network. HOME is the home directory for a task, in this case, the top directory.

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

On a heavily used system, the /etc/crontab file can become crowded easily. There may also be instances where certain entries require different variables. For example, you may need to run some task under a different shell. To help better organize your cron tasks, you can place entries in files within the cron.d directory. The files in the cron.d directory all contain entries of the same format as those used in /etc/crontab. They may be given any name. They are treated as added crontab files, with cron checking them for tasks to run. For example, Fedora installs a smolt file in the cron.d that contains entries to run tools to gather hardware profiles.

The crontab Command

You use the crontab command to install your entries into a crontab file. To do this, first, create a text file and type your crontab entries. Save this file with any name you want, such as mycronfile. Then, to install these entries, enter crontab and the name of the text file. The crontab command takes the contents of the text file and creates a crontab file in the /var/spool/cron directory, adding the name of the user who issued the command. In the following example, the root user installs the contents of mycronfile as the root's crontab file. This creates a file called /var/spool/cron/root. If a user named justin installed a crontab file, it would create a file called /var/spool/cron/justin. You can control the use of the crontab command by regular users with the /etc/cron.allow file. Only users with their names in this file can create crontab files of their own. Conversely, the /etc/cron.deny file lists those users denied use of the cron tool, preventing them for scheduling tasks. If neither file exists, access is denied to all users. If a user is not in a /etc/cron.allow file, access is denied. However, if the /etc/cron.allow file does not exist, and the /etc/cron.deny file does, then all users not listed in /etc/cron.deny are automatically allowed access.

crontab mycronfile

Never try to edit your crontab file directly. Instead, use the crontab command with the  -e option. This opens your crontab file in the /var/spool/cron directory with the standard text editor, such as vi. crontab uses the default editor as specified by the EDITOR shell environment variable. To use a different editor for crontab, change the default editor by assigning the editor’s program name to the EDITOR variable and exporting that variable. Normally, the editor variable is set in the /etc/profile script.

Running crontab with the -l option displays the contents of your crontab file, and the  -r option deletes the entire file. Invoking crontab with another text file of crontab entries overwrites your current crontab file, replacing it with the contents of the text file.

Organizing Scheduled Tasks

You can organize administrative cron tasks into two general groups: common administrative tasks that can be run at regular intervals, or specialized tasks that need to be run at a unique time. Unique tasks can be run as entries in the /etc/crontab file, as described in the next section. Common administrative tasks, though they can be run from the /etc/crontab file, are better organized into specialized cron directories. Within such directories, each task is placed in its own shell script that will invoke the task when run. For example, there may be several administrative tasks that all need to be run each week on the same day, say if maintenance for a system is scheduled on a Sunday morning. For these kinds of task, cron provides several specialized directories for automatic daily, weekly, monthly, and yearly tasks. Each contains a cron prefix and a suffix for the time interval. The /etc/cron.daily directory is used for tasks that need to be performed every day, whereas weekly tasks can be placed in the /etc/cron.weekly directory. The cron directories are listed in Table 17-5.

cron Files and Directories

Description

/etc/crontab

System crontab file, accessible only by the root user

/etc/cron.d

Directory containing multiple crontab files, accessible only by the root user

/etc/cron.hourly

Directory for tasks performed hourly

/etc/cron.daily

Directory for tasks performed daily

/etc/cron.weekly

Directory for tasks performed weekly

/etc/cron.monthly

Directory for tasks performed monthly

/etc/cron.yearly

Directory for tasks performed yearly

/etc/cron.hourly

Directory for tasks performed hourly

/etc/cron.allow

Users allowed to submit cron tasks

/etc/cron.deny

Users denied access to cron

Table 17-5: Cron Files and Directories

Running cron Directory Scripts

Each directory contains scripts that are all run at the same time. The scheduling for each group is determined by an entry in the /etc/crontab file. The actual execution of the scripts is performed by the /usr/bin/run-parts script, which runs all the scripts and programs in a given directory.

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

Scheduling for all the tasks in a given directory is handled by an entry in the /etc/crontab file. Fedora provides entries with designated times, which you may change for your own needs.

The default Fedora crontab file is shown above, with times for running scripts in the different cron directories. Here you can see that most scripts are run at about 4 a.m. either daily (4:02), Sunday (4:22), or first day of each month (4:42). Hourly ones are run one minute after the hour.

Tip: Scripts within a cron directory are run alphabetically. If you need a certain script to run before any others, you may have to alter its name. One method is to prefix the name with a numeral. For example, in the /cron.weekly directory, the anacron script is named 0anacron so that it will run before any others.

Keep in mind though that these are simply directories that contain executable files. The actual scheduling is performed by the entries in the /etc/crontab file. For example, if the weekly field in the cron.weekly crontab entry is entry is changed to * instead of 0, and the monthly field to 1(22 4 1 * * instead of 22 4 * * 0), tasks in the cron.weekly file would end up running monthly instead of weekly.

The names used for these directories are merely conventions. They have no special meaning to the cron daemon. You could, in fact, create your own directory, place scripts within it, and schedule run-parts to run those scripts at a given time. In the next example, scripts placed in the /etc/cron.mydocs directory will run at 12 noon every Wednesday.

* 12 * * 3 root run-parts /etc/cron.mydocs

Anacron

For a system that may normally be shut down during times that cron is likely to run, you may want to supplement cron with anacron. anacron activates only when scheduled tasks need to be executed. For example, if a system is shut down on a weekend when cron jobs are scheduled, then the jobs will not be performed; anacron, however, checks to see what jobs need to be performed when the system is turned on again and then runs them. It is designed only for jobs that run daily or weekly.

For anacron jobs, you place crontab entries in the /etc/anacrontab file. For each scheduled task, you specify the number of intervening days when it is executed (7 is weekly, 30 is monthly), the time of day it is run (numbered in minutes), a description of the task, and the command to be executed. For backups, the command used would be tar operation. You can use systemctl or cockpit to turn on the anacron service or have it start up automatically at boot time.

Grand Unified Bootloader (GRUB2)

With Linux, you have the ability to load different versions of the Linux kernel as well as other operating systems that you have installed on your system. The task of selecting and starting up an operating system or kernel is managed by a boot management utility, the Grand Unified Bootloader version 2 (GRUB2). This is a versatile tool, letting you load operating systems installed on your hard drives, as well as letting you choose from different Linux kernels that may be installed on the same Linux system.

With Grub, users can select operating systems to run from a menu interface displayed when a system boots up. Use arrow keys to move to an entry and press enter. Linux and Unix operating systems are known as multi-boot operating systems and take arguments passed to them at boot time. Type e to edit a command, letting you change kernel arguments or specify a different kernel. The c command places you in a command line interface. Provided your system BIOS supports very large drives, GRUB can boot from anywhere on them. Check the grub Man page for Grub options.

https://fedoraproject.org/wiki/GRUB_2

Fedora uses GRUB2 which uses the configuration file /etc/default/grub. GRUB2 files are kept in the /etc/grub.d directory. Run as root the following grub2-mkconfig to apply changes made in /etc/default/grub.

grub2-mkconfig -o /boot/grub2/grub.cfg

With Grub2, configuration is placed in user-modifiable configuration files held in the /etc/default/grub file and in the /etc/grub.d directory. There is a Grub2 configuration file called /boot/grub/grub.cfg, but this file is generated by Grub each time the system starts up, and should never be edited by a user. Instead, you would edit the /etc/default/grub file to set parameters like the default operating system to boot. To create your own menu entries, you create entries for them in the /etc/grub.d/40_custom file.

Grub options are set by assigning values to Grub options in the /etc/default/grub file. You can edit the file directly to change these options. To edit the file with the Gedit editor, open a terminal window and enter the following command. You will be prompted to enter your password.

sudo nano /etc/default/grub

On dual boot systems (those with both Fedora and Windows or Mac), the option that users are likely to change is GRUB_DEFAULT, which sets the operating system or kernel to boot automatically if one is not chosen. The option uses a line number to indicate an entry in the Grub boot menu, with numbering starting from 0 (not 1). First, check your Grub menu when you boot up (press any key on boot to display the Grub menu for a longer time), and then count to where the entry of the operating system you want to make the default is listed. If the Windows entry is at 4th, which would be line 3 (counting from 0), to make it the default you would set the GRUB_DEAULT option to 3.

GRUB_DEFAULT=3 

You can also do a search of the /boot/grub2/grub.cfg file for the menuentry pattern to display a list of all your menu entries. Use cut to display the second column as delimited by single quotes (-d "'" -f2).  

grep ^menuentry /boot/grub2/grub.cfg  | cut -d "'" -f2

Should the listing of operating systems and kernels change (adding or removing kernels), you would have to edit the /etc/default/grub file again and each time a change occurs. A safer way to set the default is to configure GRUB to use the grub-set-default command. First, edit the /etc/default/grub file and change the option for GRUB_DEFAULT to saved.

GRUB_DEFAULT=saved

Then update GRUB.

grub2-mkconfig -o /boot/grub2/grub.cfg

The grub2-set-default command takes as its option the number of the default you want to set (numbering from 0) or the name of the kernel or operating system. The following sets the default to 0, the first kernel entry.

sudo grub2-set-default 0

For a kernel name or operating system, you can use the name as it appears on the GRUB menu (enclosing the name in quotes), such as:

sudo grub2-set-default  'Windows (loader) (on /dev/sda1)'

The GRUB_TIMEOUT option sets the number of seconds Grub will wait to allow a user to access the menu, before booting the default operating system. The default options used for Fedora kernels are listed by the GRUB_CMDLINE_LINUX option. Currently, these include the rhgb and quiet options to display the Fedora emblem on start up, but not the list of startup tasks being performed (quiet).

Once you have made your changes, you have to run the grub2-mkconfig command. Otherwise, your changes will not take effect. This command will generate a new /etc/grub/grub.cfg file, which determines the actual Grub 2 configuration.

grub2-mkconfig -o /boot/grub2/grub.cfg

You can add your own Grub2 boot entries by placing them in the /etc/grub.d/40_custom file. The file is nearly empty except for an initial exec tail command that you must take care not to change. After you make your additions to the 40_custom file, you have to update GRUB to have the changes take effect.

Referencing the kernel

The linux option specifies the kernel to run. The kernel is located in the /boot directory and has the name vmlinuz with the kernel version number. You can have several kernels in the /boot directory and use GRUB to choose the one to use. After the kernel program, you specify any options you want for the kernel. This includes a ro option which initially starts the kernel as read only. The root option is used to specify the device on which your system was installed, your root directory. For the Fedora server, the device name is /dev/mapper/fedora-root.

If you installed the Fedora Workstation configuration, your root directory will be installed on fedora_localhost--live-root. The rhgb quiet options use the Red Hat Graphical Boot interface to start your system, instead of listing all the startup messages on a text display. If you are having startup problems with your graphic card driver, you may need to remove rhgb quiet from your kernel option GRUB linux line. 

Dracut options (initramfs RAM file system)

Fedora uses the Dracut initramfs RAM file system to speed up the boot process by relying on udev to detect the file system devices so that the root file system can be mounted quickly. Its aim is to rely as little as possible on hard-coded operations. Dracut is installed on Fedora by default (dracut package). Check the dracut.cmdline man page for more details, along with a complete set of options. Also, check the Dracut site at:

https://fedoraproject.org/wiki/Dracut

Dracut uses kernel parameters listed on the GRUB kernel command line to configure the initramfs RAM file system on the fly, providing more flexibility and further cutting down on RAM file system code. The default Fedora installation lists several Dracut kernel options in the kernel line for the Grub menu. You can modify these options on the GRUB_CMDLINE_LINUX option in the /etc/default/grub file.

The rd.lvm.lv option activates the root and swap logical volumes, rd.luks=0 disables LUKS files system encryption, rd.md=0 disables MD raid devices and rd.dm=0 disables DM raid devices. LANG specifes the language and character set, vconsole.font specifies the system console font, and vconsole.keymap sets the keyboard type. The dracut man page shows a complete list of options.

rd.lvm.lv=fedora/root
rd.lvm.lv=fedora/swap
rd.luks=0
rd.md=0
rd.dm=0
LANG=en_US.UTF-8
vconsole.font=latarcyrheb-sun16
vconsole.keymap=us

You also can use the dracut command to create an initramfs RAM file system image. Dracut configuration is held in the /etc/dracut.conf file and /etc/dracut.conf.d directory. See the dracut.conf man page for configuration details. A sample /etc/dracut.conf file is installed which you can work from. Dracut modules, installed in the /usr/share/dracut/modules.d directory, are used to build the initramfs RAM file system. Modules such as plymouth and redhat-il8n (language) build different features needed for the boot process. Several specialized Dracut module packages also are available such as dracut-fips for integrity checks and dracut-olpc for OLPC computers. The dracut-tools package installs dracut-catimages which you can use to combine initramfs disk images, and the dracut-gencmdline command to generate the kernel command line parameters you need for an image.

Rescue

If for some reason you are not able to boot or access your system, it may be due to conflicting configurations, libraries, or applications. In this case, you can boot your Linux system in a rescue mode and then edit configuration files with a text editor such as Vi, remove the suspect libraries, or reinstall damaged software with RPM. To enter the rescue mode, To enter the rescue mode, run the Fedora Server  DVD and then select, select Rescue a Fedora System from the Troubleshooting menu.

You will boot into the command line mode with your system’s files mounted at /mnt/sysimage. You will be notified that you can use the chroot command to set your system to the / directory as the root directory. Issue the following command at the command line prompt:

chroot /mnt/sysimage

Use the cd command to move between directories. Check /etc and /etc/sysconfig for your configuration files. You can use Vi to edit your files and the less command to view them. To reinstall files, use the rpm command. When you are finished, enter the exit command.

If you have a command line system, at the boot prompt, enter

linux rescue

You can also download and create the Linux rescue CD. Just download the Linux rescue CD iso from the Fedora repository and boot with this disk.

Re-installing the boot loader

If you have a dual-boot system, where you are running Windows and Linux on the same machine, you may run into a situation where you have to reinstall your GRUB bootloader. This problem occurs if you have installed a new version of Windows after installing Linux. Windows will automatically overwrite your bootloader (alternatively, you could install your bootloader on your Linux partition instead of the MBR). You will no longer be able to access your Linux system.

All you have to do is to reinstall your bootloader. First, in rescue mode as described in the previous section.

As noted in the preceding section, this boots your system in rescue mode. Then use grub2-install and the device name of your first partition to install the bootloader. At the prompt, enter

sudo grub-install /dev/sda1

This will reinstall your current GRUB bootloader, assuming that Windows is included in the GRUB configuration. You can then reboot, and the GRUB bootloader will start up.

You then have to create a new configuration file (/boot/grub2/grub.cfg), using the grub2-mkconfig command, as follows:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

If your Linux rescue disks are unable to access your system, you can use a Fedora Workstation Live DVD to start up Fedora and then manually mount your Fedora partitions. You will have to know your partition device names (use GParted). Once they are mounted, you can access the system files on the mounted partition and make any required changes.

Tip: If even your Linux rescue discs are unable to access your system, you could use a Fedora Workstation DVD to start up Fedora, and then manually mount your Fedora partitions. You will need to know your partition device names (use GParted). Once mounted, you can access the system files on the mounted partition and make any needed changes.

Network Time Protocol, Chrony

For servers to run correctly, they need to always have the correct time. Internet time servers worldwide provide the time in the form of the Universal Time Coordinated  (UTC). Local time is then calculated using the local system's local time zone. The time is obtained from Internet time servers from an Internet connection. You have the option of using a local hardware clock instead, though this may be much less accurate.

Normally, the time on a host machine is kept in a Time of Year chip (TOY) that maintains the time when the machine is off. Its time is used when the machine is rebooted. A host using the Network Time Protocol then adjusts the time, using the time obtained from an Internet time server. If there is a discrepancy of more than 1000 seconds (about 15 minutes), the system administrator is required to manually set the time. Time servers in the public network are organized in stratum levels, the highest being 1. Time servers from a lower stratum obtain the time from those in the next higher level.

On Fedora 28, the time is synchronized for your host by the systemd-timesyncd daemon. You can manage and set the time on your host with the timedatectl command. However, if you want to set up a time server on your local network, you can use Chrony. 

For servers on your local network, you may want to set up your own time server, ensuring that all your servers are using a synchronized time. If all your servers are running on a single host system that is directly connected to the Internet and accessing an Internet time server, you will not need to set up a separate time server.

The Chrony time server is now used on the Fedora server, replacing the older NTP time server. You can find documentation for Chrony at:

https://chrony.tuxfamily.org

For  detailed documentation and configuration of Chrony on Fedora see the Fedora System Administration Guide | Servers | Configuring NTP Using the chrony Suite.

https://docs.fedoraproject.org/f28/system-administrators-guide/servers/Configuring_NTP_Using_the_chrony_Suite.html

There are man pages for the chronyd, chrony.conf, and chronyc. The command line interface for the chronyd server is chronyc.

chronyc

The Chrony server

The Chrony server name is chronyd and is managed by the /lib/systemd/system/chrony.service script.

chronyd.service

[Unit]
Description=NTP client/server
Documentation=man:chronyd(8) man:chrony.conf(5)
After=ntpdate.service sntp.service ntpd.service
Conflicts=ntpd.service systemd-timesyncd.service
ConditionCapability=CAP_SYS_TIME

[Service]
Type=forking
PIDFile=/var/run/chronyd.pid
EnvironmentFile=-/etc/sysconfig/chronyd
ExecStart=/usr/sbin/chronyd $OPTIONS
ExecStartPost=/usr/libexec/chrony-helper update-daemon
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full

[Install]
WantedBy=multi-user.target

Use the start, stop, and restart options with the systemctl command to manage the server.

sudo systemctl start chronyd

Your host systems can then be configured to use Chrony and access your Chrony time server.

The chrony.conf configuration file

The Chrony server configuration file is /etc/chrony.conf. This file lists the Internet time servers that your own time server used to determine the time. Check the chrony.conf Man page for a complete listing of the Chrony server configuration directives.

In the chrony.conf file, the server directive specifies the Internet time server's Internet address that your Chrony server uses to access the time. There is a default entry for the pool of Fedora time servers, but you can add more server entries for other time servers.  You would use the server directive for a specific time server.

pool 2.fedora.pool.ntp.org iburst

The allow directive permits access by hosts on a local network to your time server, and the deny directive denies access. Those hosts can then use your time server. The deny directive denies access to specified hosts.

You can use the cmdallow command to allow client hosts to see your time server monitoring information. A host can then run the cronyc command line interface to run monitoring command. The cmddeny will deny access. 

You can also run the time server in broadcast mode where the time is broadcasted to your network clients. Use the broadcast directive and your network's broadcast address.

broadcast 192.168.123.255

The default /etc/chrony.conf  file is shown here.

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
pool 2.fedora.pool.ntp.org iburst

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync

# Enable hardware timestamping on all interfaces that support it.
#hwtimestamp *

# Increase the minimum number of selectable sources required to adjust
# the system clock.
#minsources 2

# Allow NTP client access from local network.
#allow 192.168.0.0/16

# Serve time even if not synchronized to a time source.
#local stratum 10

# Specify file containing keys for NTP authentication.
keyfile /etc/chrony.keys

# Get TAI-UTC offset and leap seconds from the system tz database.
leapsectz right/UTC

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
#log measurements statistics tracking

cronyc

The cronyc command line interface lets you monitor your chronyd server, generating status reports, as well as letting you change the chronyd configuration as it is running. You start the cronyc interface with the cronyc command. This places you in an interactive shell with the chrony> prompt where you can enter cronyc commands. To leave the shell enter the quit command.

For security purposes, only monitoring commands can be used by normal users or from users on other hosts. The activity command will check for how many NTP sources are online, and sourcestats will list performance information for NTP sources.

$chronyc
chronyc>

Should you want to enter configuration commands you have to start chronyc as the root user. Use the sudo command. Keep in mind that the changes are not permanent. The chrony.conf file is not affected.

sudo chronyc

To set the time manually you would enter the chronyc  shell as the root user, and use the settime command to specify the time.  You may first have to run the manual command to enable the settime command.

$ sudo chronyc
chronyc> manual on
chronyc> settime Apr 7, 2018 18:24:09
chronyc> quit

.

18. Shell Configuration

Four different major shells are commonly used on Linux systems: the Bourne Again shell (BASH), the AT&T Korn shell, the TCSH shell, and the Z shell. The BASH shell is an advanced version of the Bourne shell, which includes most of the advanced features developed for the Korn shell and the C shell. TCSH is an enhanced version of the C shell, originally developed for BSD versions of UNIX. The AT&T UNIX Korn shell is open source. The Z shell is an enhanced version of the Korn shell. Although their UNIX counterparts differ greatly, the Linux shells share many of the same features. In UNIX, the Bourne shell lacks many capabilities found in the other UNIX shells. In Linux, however, the BASH shell incorporates all the advanced features of the Korn shell and C shell, as well as the TCSH shell. All four shells are available for your use, though the BASH shell is the default.

Features

Description

bash

BASH shell, /bin/bash

bsh

BASH shell, /bin/bsh (link to /bin/bash)

sh

BASH shell, /bin/sh (link to /bin/bash)

tcsh

TCSH shell, /usr/tcsh

csh

TCSH shell , /bin/csh (link to /bin/tcsh)

ksh

Korn shell, /bin/ksh (also added link /usr/bin/ksh)

zsh

Z shell, /bin/zsh

Table 18-1: Shell Invocation Command Names

The BASH shell is the default shell for most Linux distributions. If you are logging in to a command line interface, you will be placed in the default shell automatically and given a shell prompt at which to enter your commands. The shell prompt for the BASH shell is a dollar sign ($). In the GUI interface, such as GNOME or KDE, you can open a terminal window that will display a command line interface with the prompt for the default shell (BASH). Though you log in to your default shell or display it automatically in a terminal window, you can change to another shell by entering its name. tcsh invokes the TCSH shell, bash the BASH shell, ksh the Korn shell, and zsh the Z shell. You can leave a shell by pressing ctrl-d or using the exit command. You only need one type of shell to do your work. Table 18-1 shows the different commands you can use to invoke different shells. Some shells have added links you can use to invoke the same shell, like sh and bsh, which link to and invoke the bash command for the BASH shell.

This chapter describes common features of the BASH shell, such as aliases, as well as how to configure the shell to your own needs using shell variables and initialization files. The other shells share many of the same features and use similar variables and initialization files.

Though the basic shell features and configurations are shown here, you should consult the respective online manuals and FAQs for each shell for more detailed examples and explanations.

Shell Initialization and Configuration Files

Each type of shell has its own set of initialization and configuration files. The TCSH shell uses .login, .tcshrc, and .logout files in place of .profile, .bashrc, and .bash_logout. The Z shell has several initialization files: .zshenv, .zlogin, .zprofile, .zschrc, and .zlogout. See Table 18-2 for a listing. Check the Man pages for each shell to see how they are usually configured. When you install a shell, default versions of these files are automatically placed in the users’ home directories. Except for the TCSH shell, all shells use much the same syntax for variable definitions and assigning values (TCSH uses a slightly different syntax, described in its Man pages).

Filename

Function

BASH Shell

.bash_profile

Login initialization file

.bashrc

BASH shell configuration file

.bash_logout

Logout name

.bash_history

History file

/etc/profile

System login initialization file

/etc/bashrc

System BASH shell configuration file

/etc/profile.d

Directory for specialized BASH shell configuration files

/etc/bash_completion

Completion options for applications

TCSH Shell

.login

Login initialization file

.tcshrc

TCSH shell configuration file

.logout

Logout file

Z Shell

.zshenv

Shell login file (first read)

.zprofile

Login initialization file

.zlogin

Shell login file

.zshrc

Z shell configuration file

.zlogout

Logout file

Korn Shell

.profile

Login initialization file

.kshrc

KORN shell configuration file

Table 18-2: Shell Configuration Files

Configuration Directories and Files

Applications often install configuration files in a user’s home directory that contain specific configuration information, which tailors the application to the needs of that particular user. This may take the form of a single configuration file that begins with a period or a directory that contains several configuration files. The directory name will also begin with a period. For example, Mozilla installs a directory called .mozilla in the user’s home directory that contains configuration files. On the other hand, many mail applications use a single file called .mailrc to hold alias and feature settings set up by the user, though others like Evolution also have their own, .evolution. Most single configuration files end in the letters rc. FTP uses a file called .netrc. Most newsreaders use a file called .newsrc. Entries in configuration files are usually set by the application, though you can usually make entries directly by editing the file. Applications have their own set of special variables to which you can define and assign values. You can list the configuration files in your home directory with the ls -a command.

Aliases

You use the alias command to create another name for a command. The alias command operates like a macro that expands to the command it represents. The alias does not literally replace the name of the command; it simply gives another name to that command. An alias command begins with the keyword alias and the new name for the command, followed by an equal sign and the command the alias will reference.

Note: No spaces can be around the equal sign used in the alias command.

In the next example, list becomes another name for the ls command:

$ alias list=ls
$ ls
mydata today
$ list
mydata today
$

If you want an alias to be automatically defined, you have to enter the alias operation in a shell configuration file. On Fedora, aliases are defined in either the user's .bashrc file or in a .bash_aliases file. To use a .bash_aliases file, you have to first add the commands in the .bashrc file that will read the .bash_aliases file. Just edit the .bashrc file and remove the preceding # so it appears like the following:

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

You can also place aliases in the  .bashrc file directly. Some are already defined, though commented out. You can edit the .bashrc file and remove the # comment symbols from those lines to activate the aliases.

# some more ls aliases
alias ll='ls -l'
alias la='ls -A'
alias l='ls -CF'

Aliasing Commands and Options

You can also use an alias to substitute for a command and its option, but you need to enclose both the command and the option within single quotes. Any command you alias that contains spaces must be enclosed in single quotes as well. In the next example, the alias lss references the ls command with its -s option, and the alias lsa references the ls command with the -F option. The ls command with the -s option lists files and their sizes in blocks, and ls with the -F option places a slash after directory names. Notice how single quotes enclose the command and its option.

$ alias lss='ls -s'
$ lss
mydata 14   today  6   reports  1
$ alias lsa='ls -F'
$ lsa
mydata today reports/
$

Aliases are helpful for simplifying complex operations. In the next example, listlong becomes another name for the ls command with the -l option (the long format that lists all file information), as well as the -h option for using a human-readable format for file sizes. Be sure to encase the command and its arguments within single quotes so that they are taken as one argument and not parsed by the shell.

$ alias listlong='ls -lh'
$ listlong
-rw-r--r--    1 root   root   51K  Sep  18  2008 mydata
-rw-r--r--    1 root   root   16K  Sep  27  2008 today

 Aliasing Commands and Arguments

You may often use an alias to include a command name with an argument. If you execute a command that has an argument with a complex combination of special characters on a regular basis, you may want to alias it. For example, suppose you often list just your source code and object code files—those files ending in either a .c or .o. You would need to use as an argument for ls a combination of special characters such as *.[co]. Instead, you can alias ls with the .[co] argument, giving it a simple name. In the next example, the user creates an alias called lsc for the command ls.[co]:

$ alias lsc='ls *.[co]'
$ lsc
main.c main.o lib.c lib.o

 Aliasing Commands

You can also use the name of a command as an alias. This can be helpful in cases where you should use a command only with a specific option. In the case of the rm, cp, and mv commands, the -i option should always be used to ensure an existing file is not overwritten. Instead of always being careful to use the -i option each time you use one of these commands, you can alias the command name to include the option. In the next example, the rm, cp, and mv commands have been aliased to include the -i option:

$ alias rm='rm -i'
$ alias mv='mv -i'
$ alias cp='cp -i'

The alias command by itself provides a list of all aliases that have been defined, showing the commands they represent. You can remove an alias by using the unalias command. In the next example, the user lists the current aliases and then removes the lsa alias:

$ alias
lsa=ls -F
list=ls
rm=rm -i
$ unalias lsa

 Controlling Shell Operations

The BASH shell has several features that enable you to control the way different shell operations work. For example, setting the noclobber feature prevents redirection from overwriting files. You can turn these features on and off like a toggle, using the set command. The set command takes two arguments: an option specifying on or off and the name of the feature. To set a feature on, you use the -o option, and to set it off, you use the +o option. Here is the basic form:

$ set -o feature        turn the feature on
$ set +o feature        turn the feature off

Features

Description

$ set -+o feature

BASH shell features are turned on and off with the set command; -o sets a feature on and +o turns it off:
$ set -o noclobber set noclobber on
$ set +o noclobber set noclobber off

ignoreeof

Disables ctrl-d logout

noclobber

Does not overwrite files through redirection

noglob

Disables special characters used for filename expansion: *, ?, ~, and []

Table 18-3: BASH Shell Special Features

Three of the most common features are ignoreeof, noclobber, and noglob. Table 18-3 lists these different features, as well as the set command. Setting ignoreeof enables a feature that prevents you from logging out of the user shell with ctrl-d. ctrl-d is not only used to log out of the user shell, but also to end user input entered directly into the standard input. ctrl-d is used often for the Mail program or for utilities such as cat. You can easily enter an extra ctrl-d in such circumstances and accidentally log yourself out. The ignoreeof feature prevents such accidental logouts. In the next example, the ignoreeof feature is turned on using the set command with the -o option. The user can then log out only by entering the logout command.

$ set -o ignoreeof
$ ctrl-d
Use exit to logout
$

Environment Variables and Subshells: export

When you log in to your account, Linux generates your user shell. Within this shell, you can issue commands and declare variables. You can also create and execute shell scripts. When you execute a shell script, however, the system generates a subshell. You then have two shells, the one you logged in to and the one generated for the script. Within the script shell, you can execute another shell script, which then has its own shell. When a script has finished execution, its shell terminates and you return to the shell from which it was executed. In this sense, you can have many shells, each nested within the other. Variables you define within a shell are local to it. If you define a variable in a shell script, then, when the script is run, the variable is defined with that script’s shell and is local to it. No other shell can reference that variable. In a sense, the variable is hidden within its shell.

You can define environment variables in all types of shells, including the BASH shell, the Z shell, and the TCSH shell. The strategy used to implement environment variables in the BASH shell, however, is different from that of the TCSH shell. In the BASH shell, environment variables are exported. That is to say, a copy of an environment variable is made in each subshell. For example, if the EDITOR variable is exported, a copy is automatically defined in each subshell for you. In the TCSH shell, on the other hand, an environment variable is defined only once and can be directly referenced by any subshell.

Shell Variables

Description

BASH

Holds full pathname of BASH command

BASH_VERSION

Displays the current BASH version number

GROUPS

Groups that the user belongs to

HISTCMD

Number of the current command in the history list

HOME

Pathname for user’s home directory

HOSTNAME

The hostname

HOSTTYPE

Displays the type of machine the host runs on

OLDPWD

Previous working directory

OSTYPE

Operating system in use

PATH

List of pathnames for directories searched for executable commands

PPID

Process ID for shell's parent shell

PWD

User's working directory

RANDOM

Generates random number when referenced

SHLVL

Current shell level, number of shells invoked

UID

User ID of the current user

Table 18-4: Shell Variables, Set by the Shell

In the BASH shell, an environment variable can be thought of as a regular variable with added capabilities. To make an environment variable, you apply the export command to a variable you have already defined. The export command instructs the system to define a copy of that variable for each new shell generated. Each new shell will have its own copy of the environment variable. This process is called exporting variables. To think of exported environment variables as global variables is a mistake. A new shell can never reference a variable outside of itself. Instead, a copy of the variable with its value is generated for the new shell.

  Configuring Your Shell with Shell Parameters

When you log in, Linux will set certain parameters for your login shell. These parameters can take the form of variables or features. See the previous section “Controlling Shell Operations” for a description of how to set features. Linux reserves a predefined set of variables for shell and system use. These are assigned system values, in effect, setting parameters. Linux sets up parameter shell variables you can use to configure your user shell. Many of these parameter shell variables are defined by the system when you log in. Some parameter shell variables are set by the shell automatically, and others are set by initialization scripts, described later. Certain shell variables are set directly by the shell, and others are simply used by it. Many of these other variables are application specific, used for such tasks as mail, history, or editing. Functionally, it may be better to think of these as system-level variables, as they are used to configure your entire system, setting values such as the location of executable commands on your system, or the number of history commands allowable. See Table 18-4 for a partial list of shell variables set by the shell for shell-specific tasks; Table 18-5 lists some variables used by the shell for supporting other applications.

To see a complete list of your environment variables and their values, enter the set command at the shell prompt. The list is extensive and some variables have complex values.

$ set

A reserved set of keywords is used for the names of these system variables. You should not use these keywords as the names of any of your own variable names. The system shell variables are all specified in uppercase letters, making them easy to identify. Shell feature variables are in lowercase letters. For example, the keyword HOME is used by the system to define the HOME variable. HOME is a special environment variable that holds the pathname of the user’s home directory. On the other hand, the keyword noclobber is used to set the noclobber feature on or off.

Shell Variables

Description

BASH_VERSION

Displays the current BASH version number

EXINIT

Initialization commands for Ex/Vi editor

FCEDIT

Editor used by the history  command.

GROUPS

Groups that the user belongs to

HISTFILE

The pathname of the history file

HISTSIZE

Number of commands allowed for history

HISTFILESIZE

Size of the history file in lines

HISTCMD

Number of the current command in the history list

HOME

Pathname for user’s home directory

HOSTFILE

Sets the name of the hosts file, if other than /etc/hosts

IFS

Inter-field delimiter symbol

IGNOREEOF

If not set, EOF character will close the shell. Can be set to the number of EOF characters to ignore before accepting one to close the shell (default is 10)

INPUTRC

Set the inputrc configuration file for Readline (command line). Default is current directory, .inputrc. Most Linux distributions set this to /etc/inputrc

KDEDIR

The pathname location for the KDE desktop

LOGNAME

Login name

MAIL

Name of specific mail file checked by Mail utility for received messages, if MAILPATH is not set

MAILCHECK

Interval for checking for received mail

MAILPATH

List of mail files to be checked by Mail for received messages

HOSTTYPE

Linux platforms, such as i686, x86_64, or ppc

PROMPT_COMMAND

Command to be executed before each prompt, integrating the result as part of the prompt

HISTFILE

The pathname of the history file

PS1

Primary shell prompt

PS2

Secondary shell prompt

QTDIR

Location of the Qt library (used for KDE)

SHELL

Pathname of program for type of shell you are using

TERM

Terminal type

TMOUT

Time that the shell remains active awaiting input

USER

Username

UID

Real user ID (numeric)

EUID

Effective user ID (numeric). This is usually the same as the UID but can be different when the user changes IDs, as with the su command, which allows a user to become an effective root user

Table 18-5: System Environment Variables Used by the Shell

Shell Parameter Variables

Many of the shell parameter variables automatically defined and assigned initial values by the system when you log in can be changed if you wish. Some parameter variables exist whose values should not be changed, however. For example, the HOME variable holds the pathname for your home directory. Commands such as cd reference the pathname in the HOME shell variable to locate your home directory. Some of the more common of these parameter variables are described in this section. Other parameter variables are defined by the system and given an initial value that you are free to change. To do this, you redefine them and assign a new value. For example, the PATH variable is defined by the system and given an initial value; it contains the pathnames of directories where commands are located. Whenever you execute a command, the shell searches for it in these directories. You can add a new directory to be searched by redefining the PATH variable yourself so that it will include the new directory’s pathname. Still, other parameter variables exist that the system does not define. These are usually optional features, such as the EXINIT variable that enable you to set options for the Vi editor. Each time you log in, you must define and assign a value to such variables. Some of the more common parameter variables are SHELL, PATH, PS1, PS2, and MAIL. The SHELL variable holds the pathname of the program for the type of shell you log in to. The PATH variable lists the different directories to be searched for a Linux command. The PS1 and PS2 variables hold the prompt symbols. The MAIL variable holds the pathname of your mailbox file. You can modify the values for any of them to customize your shell.

Note: You can obtain a listing of the currently defined shell variables using the env command. The env command operates like the set command, but it lists only parameter variables.

 Using Initialization Files

You can automatically define parameter variables using special shell scripts called initialization files. An initialization file is a specially named shell script executed whenever you enter a certain shell. You can edit the initialization file and place in it definitions and assignments for parameter variables. When you enter the shell, the initialization file will execute these definitions and assignments, effectively initializing parameter variables with your own values. For example, the BASH shell’s .bash_profile file is an initialization file executed every time you log in. It contains definitions and assignments of parameter variables. However, the .bash_profile file is basically only a shell script, which you can edit with any text editor such as the Vi editor; changing, if you wish, the values assigned to parameter variables.

In the BASH shell, all the parameter variables are designed to be environment variables. When you define or redefine a parameter variable, you also need to export it to make it an environment variable. This means any change you make to a parameter variable must be accompanied by an export command. You will see that at the end of the login initialization file, .bash_profile, there is usually an export command for all the parameter variables defined in it.

 Your Home Directory: HOME

The HOME variable contains the pathname of your home directory. Your home directory is determined by the parameter administrator when your account is created. The pathname for your home directory is automatically read into your HOME variable when you log in. In the next example, the echo command displays the contents of the HOME variable:

$ echo $HOME
/home/chris

The HOME variable is often used when you need to specify the absolute pathname of your home directory. In the next example, the absolute pathname of reports is specified using HOME for the home directory’s path:

$ ls $HOME/reports

 Command Locations: PATH

The PATH variable contains a series of directory paths separated by colons. Each time a command is executed, the paths listed in the PATH variable are searched one by one for that command. For example, the cp command resides on the system in the directory /bin. This directory path is one of the directories listed in the PATH variable. Each time you execute the cp command, this path is searched and the cp command located. The system defines and assigns PATH an initial set of pathnames. In Linux, the initial pathnames are /bin and /usr/bin.

The shell can execute any executable file, including programs and scripts you have created. For this reason, the PATH variable can also reference your working directory; so if you want to execute one of your own scripts or programs in your working directory, the shell can locate it. No spaces are allowed between the pathnames in the string. A colon with no pathname specified references your working directory. Usually, a single colon is placed at the end of the pathnames as an empty entry specifying your working directory. For example, the pathname //bin:/usr/bin: references three directories: /bin, /usr/bin, and your current working directory.

$ echo $PATH
/bin:/usr/sbin:

You can add any new directory path you want to the PATH variable. This can be useful if you have created several of your own Linux commands using shell scripts. You can place these new shell script commands in a directory you create and then add that directory to the PATH list. Then, no matter what directory you are in, you can execute one of your shell scripts. The PATH variable will contain the directory for that script so that directory will be searched each time you issue a command.

You add a directory to the PATH variable with a variable assignment. You can execute this assignment directly in your shell. In the next example, the user chris adds a new directory, called bin, to the PATH. Although you could carefully type in the complete pathnames listed in PATH for the assignment, you can also use an evaluation of PATH—$PATH—in its place. In this example, an evaluation of HOME is also used to designate the user’s home directory in the new directory’s pathname. Notice the last colon, which specifies the working directory:

$ PATH=$PATH:$HOME/mybin:
$ export PATH
$ echo $PATH
/bin:/usr/bin::/home/chris/mybin

If you add a directory to PATH while you are logged in, the directory will be added only for the duration of your login session. When you log back in, the login initialization file, .bash_profile, will again initialize your PATH with its original set of directories. The .bash_profile file is described in detail a bit later in this chapter. To add a new directory to your PATH permanently, you need to edit your .bash_profile file and find the assignment for the PATH variable. Then, you simply insert the directory, preceded by a colon, into the set of pathnames assigned to PATH.

 Specifying the BASH Environment: BASH_ENV

The BASH_ENV variable holds the name of the BASH shell initialization file to be executed whenever a BASH shell is generated. For example, when a BASH shell script is executed, the BASH_ENV variable is checked and the name of the script that it holds is executed before the shell script. The BASH_ENV variable usually holds $HOME/.bashrc. This is the .bashrc file in the user’s home directory. (The .bashrc file is discussed later in this chapter.) You can specify a different file if you wish, using that instead of the .bashrc file for BASH shell scripts.

 Configuring the Shell Prompt

The PS1 and PS2 variables contain the primary and secondary prompt symbols, respectively. The primary prompt symbol for the BASH shell is a dollar sign ($). You can change the prompt symbol by assigning a new set of characters to the PS1 variable. In the next example, the shell prompt is changed to the -> symbol:

$ PS1= '->'
-> export PS1
->

The following table lists the codes for configuring your prompt:

Prompt Codes

Description

\!

Current history number

\$

Use $ as prompt for all users except the root user, which has the # as its prompt

\d

Current date

\#

History command number for just the current shell

\h

Hostname

\s

Shell type currently active

\t

Time of day in hours, minutes, and seconds.

\u

Username

\v

Shell version

\w

Full pathname of the current working directory

\W

Name of the current working directory

\\

Displays a backslash character

\n

Inserts a newline

\[ \]

Allows entry of terminal specific display characters for features like color or bold font

\nnn

Character specified in octal format

You can change the prompt to be any set of characters, including a string, as shown in the next example:

$ PS1="Please enter a command: "
Please enter a command: export PS1
Please enter a command: ls
mydata /reports
Please enter a command:

The PS2 variable holds the secondary prompt symbol, which is used for commands that take several lines to complete. The default secondary prompt is >. The added command lines begin with the secondary prompt instead of the primary prompt. You can change the secondary prompt just as easily as the primary prompt, as shown here:

$ PS2="@"

Like the TCSH shell, the BASH shell provides you with a predefined set of codes you can use to configure your prompt. With them, you can make the time, your username, or your directory pathname a part of your prompt. You can even have your prompt display the history event number of the current command you are about to enter. Each code is preceded by a \ symbol: \w represents the current working directory, \t the time, and \u your username; \! will display the next history event number. In the next example, the user adds the current working directory to the prompt:

$ PS1="\w $"
/home/dylan $

The codes must be included within a quoted string. If no quotes exist, the code characters are not evaluated and are themselves used as the prompt. PS1=\w sets the prompt to the characters \w, not the working directory. The next example incorporates both the time and the history event number with a new prompt:

$ PS1="\t \! ->"

The default BASH prompt is \s-\v\$ to display the type of shell, the shell version, and the $ symbol as the prompt. Fedora has changed this to a more complex command consisting of the user (\u), the hostname (\h), and the name of the current working directory (\W). The Fedora configuration is shown here, with the @ sign preceding the hostname and the current working directory preceding the $, the final prompt symbol.

$ PS1="[\u@\h \W]$"
[richard@turtle.com /home/richard]$

Fedora also includes some complex prompt definitions in the/etc/bashrc file to support color prompts and detect any remote user logins.

  Specifying Your News Server

Several shell parameter variables are used to set values used by network applications, such as web browsers or newsreaders. NNTPSERVER is used to set the value of a remote news server accessible on your network. If you are using an ISP, the ISP usually provides a Usenet news server you can access with your newsreader applications. However, you first have to provide your newsreaders with the Internet address of the news server. This is the role of the NNTPSERVER variable. News servers on the Internet usually use the NNTP protocol. NNTPSERVER should hold the address of such a news server. For many ISPs, the news server address is a domain name that begins with nntp. The following example assigns the news server address nntp.myservice.com to the NNTPSERVER shell variable. Newsreader applications automatically obtain the news server address from NNTPSERVER. Usually, this assignment is placed in the shell initialization file, .bash_profile, so that it is automatically set each time a user logs in.

NNTPSERVER=news.myservice.com
export NNTPSERVER

 Configuring Your Login Shell: .bash_profile

The .bash_profile file is the BASH shell’s login initialization file. It is a script file that is automatically executed whenever a user logs in. The file contains shell commands that define system environment variables used to manage your shell. They may be either redefinitions of system-defined variables or definitions of user-defined variables. For example, when you log in, your user shell needs to know what directories hold Linux commands. It will reference the PATH variable to find the pathnames for these directories. However, first, the PATH variable must be assigned those pathnames. In the .bash_profile file, an assignment operation does just this. Because it is in the .bash_profile file, the assignment is executed automatically when the user logs in. The root user .bash_profile script adds an operation to undefine the USERNAME variable for security purposes, unset USERNAME.

 Exporting Variables

Any new parameter variables you may add to the .bash_profile file will also need to be exported, using the export command. This makes them accessible to any subshells you may enter. You can export several variables in one export command by listing them as arguments. The .bash_profile file contains no variable definitions, though you can add ones of your own. In this case, the .bash_profile file would have an export command with a list of all the variables defined in the file. If a variable is missing from this list, you may be unable to access it. The .bashrc file contains a definition of the HISTCONTROL variable, which is then exported. You can also combine the assignment and export command into one operation as shown here for NNTPSERVER:

export NNTPSERVER=news.myservice.com

 Variable Assignments

A copy of the standard .bash_profile file, provided for you when your account is created, is listed in the next example. Notice how PATH is assigned. PATH is a parameter variable the system has already defined. PATH holds the pathnames of directories searched for any command you enter. The assignment PATH=$PATH:$HOME/bin has the effect of redefining PATH to include your bin directory within your home directory so that your bin directory will also be searched for any commands, including ones you create yourself, such as scripts or programs. The bin directory in the .local subdirectory is also searched, PATH=$PATH:$HOME/.local/bin:$HOME/bin.

.bash_profile

# .bash_profile

# Get the aliases and functions
if [  -f  ~/.bashrc ]; then
          . ~/.bashrc
fi

# User specific environment and startup programs
PATH=$PATH:$HOME/.local/bin:$HOME/bin
export PATH

Should you want to have your current working directory searched also, you can use any text editor to modify this line in your .bash_profile file PATH=$PATH:$HOME/bin. You would insert a colon : after bin. In fact, you can change this entry to add as many directories as you want to search. Making commands automatically executable in your current working directory could be a security risk, allowing files in any directory to be executed, instead of in certain specified directories. An example of how to modify your .bash_profile file is shown in the following section.

PATH=$PATH:$HOME/.local/bin:$HOME/bin:

 Editing Your BASH Profile Script

Your .bash_profile initialization file is a text file that can be edited by a text editor, like any other text file. You can easily add new directories to your PATH by editing .bash_profile and using editing commands to insert a new directory pathname in the list of directory pathnames assigned to the PATH variable. You can even add new variable definitions. If you do so, however, be sure to include the new variable’s name in the export command’s argument list. For example, if your .bash_profile file does not have any definition of the EXINIT variable, you can edit the file and add a new line that assigns a value to EXINIT. The definition EXINIT='set nu ai' will configure the Vi editor with line numbering and indentation. You then need to add EXINIT to the export command’s argument list. When the .bash_profile file executes again, the EXINIT variable will be set to the command set nu ai. When the Vi editor is invoked, the command in the EXINIT variable will be executed, setting the line number and auto-indent options automatically.

In the following example, the user’s .bash_profile has been modified to include definitions of EXINIT and redefinitions of PATH, PS1, and HISTSIZE. The PATH variable has the ending colon added to it that specifies the current working directory, enabling you to execute commands that may be located in either the home directory or the working directory. The redefinition of HISTSIZE reduces the number of history events saved, from 1,000 defined in the system’s .bash_profile file, to 30. The redefinition of the PS1 parameter variable changes the prompt to just show the pathname of the current working directory. Any changes you make to parameter variables within your .bash_profile file override those made earlier by the system’s .bash_profile file. All these parameter variables are then exported with the export command.

.bash_profile

# .bash_profile

# Get the aliases and functions
if [  -f  ~/.bashrc ]; then
          . ~/.bashrc
fi
PATH=$PATH:$HOME/.local/bin:$HOME /bin:

HISTSIZE=30
NNTPSERVER=news.myserver.com
EXINIT='set nu ai'
PS1="\w \$"
export PATH HISTSIZE EXINIT PS1 NNTPSERVER

 Manually Re-executing the .bash_profile Script

Although the .bash_profile file is executed each time you log in, it is not automatically re-executed after you make changes to it. The .bash_profile file is an initialization file that is executed whenever you log in. If you want to take advantage of any changes you make to it without having to log out and log in again, you can re-execute the .bash_profile file with the dot (.) command. The .bash_profile file is a shell script and, like any shell script, can be executed with the . command.

$ . .bash_profile

Alternatively, you can use the source command to execute the .bash_profile initialization file or any initialization file such as .login used in the TCSH shell or .bash_bashrc.

$ source .bash_profile

 System Shell Profile Script

Your Linux system also has its own profile file that it executes whenever any user logs in. This system initialization file is simply called profile and is found in the /etc directory, /etc/profile. This file contains parameter variable definitions the system needs to provide for each user. A copy of the system’s /etc/profile file follows. Fedora and Red Hat use a pathmunge function to generate a directory list for the PATH variable. Normal user paths and the root user path include the system directories (/sbin, /usr/sbin, and /usr/local/sbin). The path generated for the root user (Effective User ID of 0, EUID = 0) places the system application directories first in the path, whereas normal user paths place them after the standard application directories (/usr/local/bin, /usr/bin, /bin).

# echo $PATH
/usr/local/bin:usr/sbin:/bin:/usr/local/sbin:usr/sbin:/sbin:/home/richard/bin

A special work-around is included for the Korn Shell to set the User and Effective User IDs (EUID and UID ).

The USER, MAIL, and LOGNAME variables are set, provided that /usr/bin/id, which provides the User ID, is executable. The id command with the -un option provides the user ID’s text name only, like chris or richard.

The HOSTNAME variable is set using the /bin/hostname command

HISTSIZE is redefined to include a larger number of history events, and the HISTCONTROL variable is set to not save duplicate commands (ignoredup), and if set to ignorespace, to not save commands beginning with a space and duplicate commands (ignoreboth). 

In this example, an entry has been added here for the NNTPSERVER variable. For news servers provided by your network, the new server address should be set for all users in the system’s /etc/profile file by the system administrator.  For users that subscribe to an Internet news server directly, the news server address should be set in the individual user’s own .bash_profile file.

Note: The /etc/profile file also executes any scripts in the directory /etc/profile.d. This design allows for a more modular structure. Rather than make entries by editing the /etc/profile file, you can just add a script to profile.d directory.

Note: The /etc/profile file no longer runs the /etc/inputrc file, which configures your command line editor.

/etc/profile

# /etc/profile
# System-wide environment and startup programs, for login setup
# Functions and aliases go in /etc/bashrc
pathmunge () {
          case ":${PATH}:" in
         *:"$1":*)
             ;;
         *)
              if [ "$2" = "after" ] ; then
                    PATH=$PATH:$1
             else
                    PATH=$1:$PATH
              fi
        esac
}

if [ -x /usr/bin/id ]; then
     if [ -z "$EUID" ]; then
         # ksh workaround
          EUID=`id -u`
          UID=`id -ru`
     fi
     USER="`id -un`"
     LOGNAME=$USER
     MAIL="/var/spool/mail/$USER"
fi

# Path manipulation
if [ "$EUID" = "0" ]; then
    pathmunge /usr/sbin
    pathmunge /usr/local/sbin
else
    pathmunge /usr/local/sbin after
    pathmunge /usr/sbin after
fi

HOSTNAME=`/bin/hostname 2>/dev/null`
HISTSIZE=1000
if  [ '$HISTCONTORL" = "ignorespace' ] ; then
          export HISTCONTROL=ignoreboth
      else
          export HISTCONTROL=ignoredups
fi

export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE HISTCONTROL
If [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
    umask 002
else
    umask 822
fi

for i in /etc/profile.d/*.sh ; do
    if [ -r "$i" ]; then
        if [ "${-#*i}" != "$-" ]; then
          . "$i"
        else
         . "$i" >/dev/null
        fi
    fi
done

unset i
unset -f pathmunge

if [ -n "${BASH_VERSION-}" ] ; then
       if [ -f /etc/bashrc ] ; then
              . /etc/bashrc
       fi
fi

The number of aliases and variable settings needed for different applications would make the /etc/profile file much too large to manage. Instead, application task-specific aliases and variables are placed in separate configuration files located in the /etc/profile.d directory. There are corresponding scripts for both the BASH and C shells. Files run by the BASH shell end in the extension .sh, and those run by the C shell have the extension .csh.  The BASH shell scripts are run by /etc/profile. The scripts are named for the kinds of tasks and applications they configure. For example, colorls.sh sets the file type color coding when the ls command displays files and directories. The vim.sh file sets an alias for the vi command, executing vim whenever the user enters just vi. The kde.sh file sets the global environment variable KDEDIR, specifying the KDE Desktop applications directory, /usr. If you installed Kerberos, the krb5.sh file adds the pathnames for Kerberos, /usr/kerberos, to the PATH variable. The /etc/profile script will also check first if the PS1 variable is defined before running any /etc/profile.d scripts for console output and input (interactive mode), or to just define environmental shell variables.

Configuring the BASH Shell: .bashrc

The .bashrc file is a configuration file executed each time you enter the BASH shell or generate any subshells. If the BASH shell is your login shell, .bashrc is executed along with your .bash_login file when you log in. If you enter the BASH shell from another shell, the .bashrc file is automatically executed, and the variable and alias definitions it contains will be defined. If you enter a different type of shell, the configuration file for that shell will be executed instead. For example, if you were to enter the TCSH shell with the tcsh command, the .tcshrc configuration file would be executed instead of .bashrc.

 The User .bashrc BASH Script

The .bashrc shell configuration file is actually executed each time you generate a BASH shell, such as when you run a shell script. In other words, each time a subshell is created, the .bashrc file is executed. This has the effect of exporting any local variables or aliases you have defined in the .bashrc shell initialization file. The .bashrc file usually contains the definition of aliases and any feature variables used to turn on shell features. Aliases and feature variables are locally defined within the shell. But the .bashrc file defines them in every shell. For this reason, the .bashrc file usually holds aliases and options you want defined for each shell. As an example of how you can add your own aliases and options, aliases for the rm, cp, and mv commands and the shell noclobber and ignoreeof options have been added. For the root user .bashrc, the rm, cp, and mv aliases have already been included in the root's .bashrc file.

.bashrc

# .bashrc
# User specific aliases and functions

alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'

# Source global definitions
if [ -f /etc/bashrc ]; then
     . /etc/bashrc
fi

You can add any commands or definitions of your own to your .bashrc file. If you have made changes to .bashrc and you want them to take effect during your current login session, you need to re-execute the file with either the . or the source command.

$ . .bashrc

The System /etc/bashrc BASH Script

Fedora also has a system bashrc file executed for all users, called /etc/bashrc. Currently, the /etc/bashrc file sets the default shell prompt and checks for a login shell. If in an interactive shell,  /etc/bashrc file will determine the default prompt. If not in a login shell, it will then determine the PATH and run any profile.d scripts (these scripts were run by /etc/profile for the login shell).

Note: The bash_completion files in the /etc/bash_completion.d directory provide command completion options for applications.

The BASH Shell Logout File: .bash_logout

The .bash_logout file is also a configuration file, but it is executed when the user logs out. It is designed to perform any operations you want to occur whenever you log out. Instead of variable definitions, the .bash_logout file usually contains shell commands that form a kind of shutdown procedure, actions you always want taken before you log out. One common logout command is to clear the screen and then issue a farewell message. This is performed by the root user .bash_logout file, though not in the normal user .bash_logout files.

.bash_logout

# ~/.bash_logout

clear
echo "Good-bye for now"

As with .bash_profile, you can add your own shell commands to .bash_logout. The root user .bash_logout file includes instructions to invoke the clear command to clear the screen. In the next example, the user has added an echo command in the .bash_logout file.

19. Administering TCP/IP Networks

Linux systems are configured to connect into networks that use the TCP/IP protocols. These are the same protocols that the Internet uses, as do many local area networks (LANs). TCP/IP is a robust set of protocols designed to provide communications among systems with different operating systems and hardware. The TCP/IP protocols were developed in the 1970s as a special DARPA project to enhance communications between universities and research centers. These protocols were originally developed on UNIX systems, with much of the research carried out at the University of California, Berkeley. Linux, as a version of UNIX, benefits from much of this original focus on UNIX. Currently, the TCP/IP protocol development is managed by the Internet Engineering Task Force (IETF), which, in turn, is supervised by the Internet Society (ISOC). The ISOC oversees several groups responsible for different areas of Internet development, such as the Internet Assigned Numbers Authority (IANA), which is responsible for Internet addressing (see Table 19-1). Over the years, TCP/IP protocol standards and documentation have been issued in the form of Request for Comments (RFC) documents. Check the most recent ones for current developments at the IETF Web site at www.ietf.org.

TCP/IP Protocol Suite

The TCP/IP protocol suite actually consists of different protocols, each designed for a specific task in a TCP/IP network. The three basic protocols are the Transmission Control Protocol (TCP), which handles receiving and sending out communications, the Internet Protocol (IP), which handles the actual transmissions, and the User Datagram Protocol (UDP), which also handles receiving and sending packets. The IP protocol, which is the base protocol that all others use, handles the actual transmissions, handling the packets of data with sender and receiver information in each. The TCP protocol is designed to work with cohesive messages or data. This protocol checks received packets and sorts them into their designated order, forming the original message. For data sent out, the TCP protocol breaks the data into separate packets, designating their order. The UDP protocol, meant to work on a much more raw level, also breaks down data into packets but does not check their order. The TCP/IP protocol is designed to provide stable and reliable connections that ensure that all data is received and reorganized into its original order. UDP, on the other hand, is designed to simply send as much data as possible, with no guarantee that packets will all be received or placed in the proper order. UDP is often used for transmitting very large amounts of data of the type that can survive the loss of a few packets—for example, temporary images, video, and banners displayed on the Internet.

Other protocols provide various network and user services. The Domain Name Service (DNS) provides address resolution. The File Transfer Protocol (FTP) provides file transmission, and the Network File System (NFS) provides access to remote file systems. Table 19-2 lists the different protocols in the TCP/IP protocol suite. These protocols make use of either the TCP or UDP protocol to send and receive packets, which, in turn, uses the IP protocol for actually transmitting the packets.

In a TCP/IP network, messages are broken into small components, called datagrams, which are then transmitted through various interlocking routes and delivered to their destination computers. Once received, the datagrams are reassembled into the original message. Datagrams themselves can be broken down into smaller packets. The packet is the physical message unit actually transmitted among networks. Sending messages as small components has proved to be far more reliable and faster than sending them as one large, bulky transmission. With small components, if one is lost or damaged, only that component must be resent, whereas if any part of a large transmission is corrupted or lost, the entire message has to be resent.

Group

Title

Description

ISOC

Internet Society

Professional membership organization of Internet experts that oversees boards and task forces dealing with network policy issues
www.isoc.org

IESG

The Internet Engineering Steering Group

Responsible for technical management of IETF activities and the Internet standards process
www.ietf.org/iesg.html

IANA

Internet Assigned Numbers Authority

Responsible for Internet Protocol (IP) addresses
www.iana.org

IAB

Internet Architecture Board

Defines the overall architecture of the Internet, providing guidance and broad direction to the IETF
www.iab.org

IETF

Internet Engineering Task Force

Protocol engineering and development arm of the Internet
www.ietf.org

Table 19-1: TCP/IP Protocol Development Groups

The configuration of a TCP/IP network on your Linux system is implemented using a set of network configuration files (Table 19-6 provides a complete listing). Many of these can be managed using administrative programs, such as system-config-network on your desktop. You can also use the more specialized programs, such as netstat, ifconfig, Wireshark, and route. Some configuration files are easy to modify yourself using a text editor.

TCP/IP networks are configured and managed with a set of utilities: ifconfig, route, and netstat. The ifconfig utility operates from your root user desktop and enables you to configure your network interfaces fully, adding new ones and modifying others. The ifconfig and route utilities are lower-level programs that require more specific knowledge of your network to use effectively. The netstat utility provides you with information about the status of your network connections. Wireshark is a network protocol analyzer that lets you capture packets as they are transmitted across your network, selecting those you want to check.

Zero Configuration Networking: Avahi and Link Local Addressing

Zero Configuration Networking (Zeroconf) allows the setup of nonroutable private networks without the need of a DHCP server or static IP addresses. A Zeroconf configuration lets users automatically connect to a network and access all network resources, such as printers, without having to perform any configuration. On Linux, Zeroconf networking is implemented by Avahi (https://avahi.org), which includes multicast DNS (mDNS) and DNS service discovery (DNS-SD) support that automatically detects services on a network. IP addresses are determined using either IPv6 or IPv4 Link Local (IPv4LL) addressing. IPv4 Link Local addresses are assigned from the 168.254.0.0 network pool. Derived from Apple’s Bonjour Zeroconf implementation, it is a free and open source version currently used by desktop tools such as the GNOME virtual file system. Fedora implements full Zeroconf network support with the Avahi daemon that implements multicast DNS discover, and avahi-autoipd that provides dynamic configuration of local IPv4 addresses. Both are installed as part of the desktop configuration. Avahi support tools like avahi-browse and avahi-publish are located in the avahi-tools package. Specialized tools like SSH and Shell tools are located in the avahi-ui-tools package.

The KDE Zeroconf solution is provided using Avahi (kdnssd) located in the kdnnsd-avahi packages. Use the KDE control center Service Discovery panel (Internet & Network section) to specify your domain. Then enter zeorconf:/ in a KDE file manager window.

IPv4 and IPv6

Traditionally, a TCP/IP address is organized into four segments, consisting of numbers separated by periods. This is called the IP address. The IP address actually represents a 19-bit integer whose binary values identify the network and host. This form of IP addressing adheres to Internet Protocol, version 4, also known as IPv4. IPv4, the kind of IP addressing described here, is still in wide use.

Currently, a new version of the IP protocol called Internet Protocol, version 6 (IPv6) is gradually replacing the older IPv4 version. IPv6 expands the number of possible IP addresses by using 128 bits. It is fully compatible with systems still using IPv4. IPv6 addresses are represented differently, using a set of eight 16-bit segments, each separated from the next by a colon. Each segment is represented by a hexadecimal number. A sample address would be

FC00:0:0:0:800:BA98:7654:3210

Advantages of IPv6 include the following:

IPv6 features simplified headers that allow for faster processing.

IPv6 provides support for encryption and authentication along with virtual private networks (VPN) using the integrated IPsec protocol.

One of its most significant advantages lies in its extending the address space to cover 2 to the power of 128 possible hosts (billions of billions). This extends far beyond the 4.2 billion supported by IPv4.

IPv6 supports stateless autoconfiguration of addresses for hosts, bypassing the need for DHCP to configure such addresses. Addresses can be generated directly using the MAC (Media Access Control) hardware address of an interface.

IPv6 provides support for Quality of Service (QoS) operations, providing sufficient response times for services like multimedia and telecom tasks.

Multicast capabilities are built into the protocol, providing direct support for multimedia tasks. Multicast addressing also provides that same function as IPv4 broadcast addressing.

More robust transmissions can be ensured with anycast addressing, where packets can be directed to an anycast group of systems, only one of which needs to receive them. Multiple DNS servers supporting a given network could be designated as an anycast group, of which only one DNS server needs to receive the transmission, providing a greater likelihood that the transmissions will go through.

IPv6 provides better access for mobile nodes, like PDAs, notebooks, and cell phones.

Transport

Description

TCP

Transmission Control Protocol; places systems in direct communication

UDP

User Datagram Protocol

IP

Internet Protocol; transmits data

ICMP

Internet Control Message Protocol; status messages for IP

Routing

Description

RIP

Routing Information Protocol; determines routing

OSPF

Open Shortest Path First; determines routing

Network Addresses

Description

ARP

Address Resolution Protocol; determines unique IP address of systems

DNS

Domain Name Service; translates hostnames into IP addresses

RARP

Reverse Address Resolution Protocol; determines addresses of systems

User Service

Description

FTP

File Transfer Protocol; transmits files from one system to another (TCP)

TFTP

Trivial File Transfer Protocol; transfers files using UDP

Telnet

Remote login to another system on the network

SMTP

Simple Mail Transfer Protocol; transfers e-mail between systems

RPC

Remote Procedure Call; allows programs on remote systems to communicate

Gateway

Description

EGP

Exterior Gateway Protocol; provides routing for external networks

GGP

Gateway-to-Gateway Protocol; provides routing between Internet gateways

IGP

Interior Gateway Protocol; provides routing for internal networks

Network Service

Description

NFS

Network File System; allows mounting of remote file systems

NIS 

Network Information Service; maintains user accounts across a network

BOOTP

Boot Protocol; starts system using boot information on server for network

SNMP

Simple Network Management Protocol; provides status messages on TCP/IP configuration

DHCP

Dynamic Host Configuration Protocol; automatically provides network configuration information to host systems

Table 19-2: TCP/IP Protocol Suite

TCP/IP Network Addresses

As noted previously, the traditional IPv4 TCP/IP address is organized into four segments, consisting of numbers separated by periods. This kind of address is still in widespread use and is what people commonly refer to as an IP address. Part of an IP address is used for the network address, and the other part is used to identify a particular interface on a host in that network. You should realize that IP addresses are assigned to interfaces—such as Ethernet cards or modems—and not to the host computer. Usually, a computer has only one interface and is accessed using only that interface’s IP address. In that regard, an IP address can be thought of as identifying a particular host system on a network, and so the IP address is usually referred to as the host address.

In fact, though, a host system could have several interfaces, each with its own IP address. This is the case for computers that operate as gateways and firewalls from a local network to the Internet. One interface usually connects to the LAN and another to the Internet, as by two Ethernet cards. Each interface (such as an Ethernet card) has its own IP address. For example, when you use the system-config-network tool to specify an IP address for an Ethernet card on your system, the Devices tab lists an entry for each Ethernet card installed on your computer. Opening up a Device window, you can select the TCP protocol in the Protocols tab to open a TCP/IP setting window where you can enter the card’s IP address. Other Ethernet cards have their own IP addresses. If you use a modem to connect to an ISP, you would set up a Point-to-Point (PPP) interface that would also have its own IP address (usually dynamically assigned by the ISP). This distinction is important if you plan to use Linux to set up a local or home network, using Linux as your gateway machine to the Internet

 IPv4 Network Addresses

The IP address is divided into two parts: one part identifies the network, and the other part identifies a particular host. The network address identifies the network of which a particular interface on a host is a part. Two methods exist for implementing the network and host parts of an IP address: the original class-based IP addressing and the current Classless Interdomain Routing (CIDR) addressing. Class-based IP addressing designates officially predetermined parts of the address for the network and host addresses, whereas CIDR addressing allows the parts to be determined dynamically using a netmask.

 Class-Based IP Addressing

Originally, IP addresses were organized according to classes. On the Internet, networks are organized into three classes depending on their size—classes A, B, and C. A class A network uses only the first segment for the network address and the remaining three for the host, allowing a great many computers to be connected to the same network. Most IP addresses reference smaller, class C, networks. For a class C network, the first three segments are used to identify the network, and only the last segment identifies the host. Altogether, this forms a unique address with which to identify any network interface on computers in a TCP/IP network. For example, in the IP address 192.168.1.72, the network part is 192.168.1 and the interface/host part is 72. The interface/host is a part of a network whose own address is 192.168.1.0.

In a class C network, the first three numbers identify the network part of the IP address. This part is divided into three network numbers, each identifying a subnet. Networks on the Internet are organized into subnets, beginning with the largest and narrowing to small subnetworks. The last number is used to identify a particular computer, referred to as a host. You can think of the Internet as a series of networks with subnetworks; these subnetworks have their own subnetworks. The rightmost number identifies the host computer, and the number preceding it identifies the subnetwork of which the computer is a part. The number to the left of that identifies the network the subnetwork is part of, and so on. The Internet address 192.168.187.4 references the fourth computer connected to the network identified by the number 187. Network 187 is a subnet to a larger network identified as 168. This larger network is itself a subnet of the network identified as 192. Here’s how it breaks down:

192.168.187.4

IPv4 address

192.168.187

Network identification

4

Host identification

Netmask

Systems derive the network address from the host address using the netmask. You can think of an IP address as a series of 32 binary bits, some of which are used for the network and the remainder for the host. The netmask has the network set of bits set to 1s, with the host bits set to 0s (see Figure 19-1). In a standard class-based IP address, all the numbers in the network part of your host address are set to 255, and the host part is set to 0. This has the effect of setting all the binary bits making up the network address to 1s. This, then, is your netmask. So, the netmask for the host address 192.168.1.72 is 255.255.255.0. The network part, 192.168.1, has been set to 255.255.255, and the host part, 72, has been set to 0. Systems can then use your netmask to derive your network address from your host address. They can determine what part of your host address makes up your network address and what those numbers are.

For those familiar with computer programming, a bitwise AND operation on the netmask and the host address results in zeroing the host part, leaving you with the network part of the host address. You can think of the address as being implemented as a four-byte integer, with each byte corresponding to a segment of the address. In a class C address, the three network segments correspond to the first three bytes and the host segment corresponds to the fourth byte. A netmask is designed to mask out the host part of the address, leaving the network segments alone. In the netmask for a standard class C network, the first three bytes are all 1s and the last byte consists of 0s. The 0s in the last byte mask out the host part of the address, and the 1s in the first three bytes leave the network part of the address alone. Figure 19-1 shows the bitwise operation of the netmask on the address 192.168.1.4. This is a class C address to the mask, which consists of twenty-four 1s making up the first three bytes and eight 0s making up the last byte. When it is applied to the address 192.168.1.4, the network address remains (192.168.1) and the host address is masked out (4), giving you 192.168.1.0 as the network address.

The netmask as used in Classless Interdomain Routing (CIDR) is much more flexible. Instead of having the size of the network address and its mask determined by the network class, it is determined by a number attached to the end of the IP address. This number simply specifies the size of the network address, how many bits in the address it takes up. For example, in an IP address whose network part takes up the first three bytes (segments), the number of bits used for that network part is 24—eight bits to a byte (segment). Instead of using a netmask to determine the network address, the number for the network size is attached to the end of the address with a slash, as shown here:

192.168.1.72/24

CIDR gives you the advantage of specifying networks that are any size bits, instead of only three possible segments. You could have a network whose addresses take up 14 bits, 22 bits, or even 25 bits. The host address can use whatever bits are left over. An IP address with 21 bits for the network can cover host addresses using the remaining 11 bits, 0 to 2,047.

Classless Interdomain Routing (CIDR)

Currently, the class-based organization of IP addresses is being replaced by the CIDR format. CIDR was designed for midsized networks, those between a class C and classes with numbers of hosts greater than 256 and smaller than 65,534. A class C network–based IP address uses only one segment, an 8-bit integer, with a maximum value of 256. A class B network–based IP address uses two segments, which make up a 16-bit integer whose maximum value is 65,534. You can think of an address as a 19-bit integer taking up four bytes, where each byte is 8 bits. Each segment conforms to one of the four bytes. A class C network uses three segments, or 24 bits, to make up its network address. A class B network, in turn, uses two segments, or 16 bits, for its address. With this scheme, allowable host and network addresses are changed an entire byte at a time, segment to segment. With CIDR addressing, you can define host and network addresses by bits, instead of whole segments. For example, you can use CIDR addressing to expand the host segment from 8 bits to 9, rather than having to jump it to a class B 16 bits (two segments).

Figure 19-1: Class based netmask operations

CIDR addressing notation achieves this by incorporating netmask information in the IP address (the netmask is applied to an IP address to determine the network part of the address). In the CIDR notation, the number of bits making up the network address is placed after the IP address, following a slash. For example, the CIDR form of the class C 192.168.187.4 IP address is

192.168.187.4/24

Figure 19-2 shows an example of a CIDR address and its network mask. The IP address is 192.168.1.6 with a network mask of 22 bits, 192.168.1.6/22. The network address takes up the first 22 bits of the IP address, and the remaining 10 bits are used for the host address. The host address is taking up the equivalent of a class-based IP address’s fourth segment (8 bits) and 2 bits from the third segment.

Figure 19-2: CIDR addressing

Table 19-3 lists the different IPv4 CIDR network masks available along with the maximum number of hosts. Both the short forms and the full forms of the netmasks are listed.

Short Form

Full Form

Maximum Number of Hosts

/8

/255.0.0.0

16,777,215 (A class)

/16

/255.255.0.0

65,535 (B class)

/17

/255.255.128.0

32,767

/18

/255.255.192.0

16,383

/19

/255.255.224.0

8,191

/20

/255.255.240.0

4,095

/21

/255.255.248.0

2,047

/22

/255.255.252.0

1,023

/23

/255.255.254.0

511

/24

/255.255.255.0

255 (C class)

/25

/255.255.255.128

127

/26

/255.255.255.192

63

/27

/255.255.255.224

31

/28

/255.255.255.240

15

/29

/255.255.255.248

7

/30

/255.255.255.252

3

Table 19-3: CIDR IPv4 Network Masks

IPv4 CIDR Addressing

The network address for any standard class C IPv4 IP address takes up the first three segments, 24 bits. If you want to create a network with a maximum of 512 hosts, you can give them IP addresses where the network address is 23 bits and the host address takes up 9 bits (0–511). The IP address notation remains the same, however, using the four 8-bit segments. This means a given segment’s number could be used for both a network address and a host address. Segments are no longer wholly part of either the host address or the network address. Assigning a 23-bit network address and a 9-bit host address means that the number in the third segment is part of the network address and the host address, the first 7 bits for the network and the last bit for the host. In this following example, the third number, 145, is used as the end of the network address and as the beginning of the host address:

192.168.145.67/23

This situation complicates CIDR addressing, and in some cases, the only way to represent the address is to specify two or more network addresses. Check RFC 1520 at www.ietf.org for more details.

CIDR also allows a network administrator to take what is officially the host part of an IP address and break it up into subnetworks with fewer hosts. This is referred to as subnetting. A given network will have its official IP network address recognized on the Internet or by a larger network. The network administrator for that network could, in turn, create several smaller networks within it using CIDR network masking. A classic example is to take a standard class C network with 254 hosts and break it up into two smaller networks, each with 64 hosts. You do this by using a CIDR netmask to take a bit from the host part of the IP address and use it for the subnetworks. Numbers within the range of the original 254 addresses whose first bit would be set to 1 would represent one subnet, and the others, whose first bit would be set to 0, would constitute the remaining network. In the network whose network address is 192.168.187.0, where the last segment is used for the hostnames, that last host segment could be further split into two subnets, each with its own hosts. For two subnets, you would use the first bit in the last 8-bit segment for the network. The remaining 7 bits could then be used for host addresses, giving you a range of 127 hosts per network. The subnet whose bit is set to 0 would have a range of 1 to 127, with a CIDR netmask of 25. The 8-bit segment for the first host would be 00000001. So the host with the address of 1 in that network would have this IP address:

192.168.187.1/25

For the subnet where the first bit is 1, the first host would have an address of 129, with the CIDR netmask of 25, as shown here. The 8-bit sequence for the first host would be 10000001.

192.168.187.129/25

Note: A simple way to calculate the number of hosts a network can address is to take the number of bits in its host segment as a power of 2, and then subtract 2—that is, 2 to the number of host bits, minus 2. For example, an 8-bit host segment would be 2 to the power of 8, which equals 256. Subtract 2 (1 for the broadcast address, 255, and 1 for the zero value, 000) to leave you with 254 possible hosts.

Each subnet would have a set of 126 addresses, the first from 1 to 126, and the second from 129 to 254; 127 is the broadcast address for the first subnet, and 128 is the network address for the second subnet. The possible subnets and their masks that you could use are shown here:

Subnetwork

CIDR Address

Binary Mask

First subnet network address

.0/25

00000000

Second subnet network address

.128/25

10000000

First subnet broadcast address

.127/25

01111111

Second subnet broadcast address

.255/25

11111111

First address in first subnet

.1/25

00000001

First address in second subnet

.129/25

10000001

Last address in first subnet

.126/25

01111110

Last address in second subnet

.254/25

11111110

 IPv6 CIDR Addressing

IPv6 CIDR addressing works much the same as with the IPv4 method. The number of bits used for the network information is indicated by the number following the address. A host (interface) address could take up much more than the 64 bits that it usually does in an IPv6 address, making the network prefix (address) section smaller than 64 bits. How many bits that the network prefix uses is indicated by the following number. In the next example, the network prefix (address) uses only the first 48 bits of the IPv6 address, and the host address uses the remaining 80 bits:

FC00:0000:0000:0000:FEDC:BA98:7654:3210/48

You can also use a two-colon notation (::) for the compressed version:

FC00::FEDC:BA98:7654:3210/48

Though you can use CIDR to subnet addresses, IPv6 also supports a subnet field that can be used for subnets.

 Obtaining an IP Address

IP addresses are officially allocated by IANA, which manages all aspects of Internet addressing (www.iana.org). IANA oversees Internet Registries, which, in turn, maintain Internet addresses on regional and local levels. The Internet Registry for the Americas is the American Registry for Internet Numbers (ARIN), whose Web site is at www.arin.net. These addresses are provided to users by Internet service providers (ISPs). You can obtain your own Internet address from an ISP, or if you are on a network already connected to the Internet, your network administrator can assign you one. If you are using an ISP, the ISP may temporarily assign one from a pool it has on hand with each use.

 IPv4 Reserved Addresses

Certain numbers are reserved. The numbers 127, 0, or 255 cannot be part of an official IP address. The number 127 is used to designate the network address for the loopback interface on your system. The loopback interface enables users on your system to communicate with each other within the system without having to route through a network connection. Its network address would be 127.0.0.0, and its IP address is 127.0.0.1. For class-based IP addressing, the number 255 is a special broadcast identifier you can use to broadcast messages to all sites on a network. Using 255 for any part of the IP address references all nodes connected at that level. For example, 192.168.255.255 broadcasts a message to all computers on network 192.168, all its subnetworks, and their hosts. The address 192.168.187.255 broadcasts to every computer on the local network. If you use 0 for the network part of the address, the host number references a computer within your local network. For example, 0.0.0.6 references the sixth computer in your local network. If you want to broadcast to all computers on your local network, you can use the number 0.0.0.255. For CIDR IP addressing, the broadcast address may appear much like a normal IP address. As indicated in the preceding section, CIDR addressing allows the use of any number of bits to make up the IP address for either the network or the host part. For a broadcast address, the host part must have all its bits set to 1 (see Figure 19-3).

Figure 19-3: Class based and CIDR broadcast addressing

A special set of numbers is reserved for use on non-Internet LANs (RFC 1918). These are numbers that begin with the special network number 192.168 (for class C networks), as used in these examples. If you are setting up a LAN, such as a small business or a home network, you are free to use these numbers for your local machines. You can set up an intranet using network cards, such as Ethernet cards and Ethernet hubs, and then configure your machines with IP addresses starting from 192.168.1.1. The host segment can go up to 256. If you have three machines on your home network, you could give them the addresses 192.168.1.1, 192.168.1.2, and 192.168.1.3. You can implement Internet services, such as FTP, Web, and mail services, on your local machines and use any of the Internet tools to make use of those services. They all use the same TCP/IP protocols used on the Internet. For example, with FTP tools, you can transfer files among the machines on your network. With mail tools, you can send messages from one machine to another, and with a Web browser, you can access local Web sites that may be installed on a machine running its own Web servers. If you want to have one of your machines connected to the Internet or some other network, you can set it up to be a gateway machine. By convention, the gateway machine is usually given the address 192.168.1.1. With a method called IP masquerading, you can have any of the non-Internet machines use a gateway to connect to the Internet.

Numbers are also reserved for class A and class B non-Internet local networks. Table 19-4 lists these addresses. The possible addresses available span from 0 to 255 in the host segment of the address. For example, class B network addresses range from 172.16.0.0 to 172.31.255.255, giving you a total of 32,356 possible hosts. The class C network ranges from 192.168.0.0 to 192.168.255.255, giving you 256 possible subnetworks, each with 256 possible hosts. The network address 127.0.0.0 is reserved for a system’s loopback interface, which allows it to communicate with itself, enabling users on the same system to send messages to each other.

IPv4 Private Network Addresses

Network Classes

10.0.0.0

Class A network

172.16.0.0–172.31.255.255

Class B network

192.168.0.0

Class C network

127.0.0.0

Loopback network (for system self-communication)

Table 19-4: Non-Internet IPv4 Local Network IP Addresses

Broadcast Addresses

The broadcast address allows a system to send the same message to all systems on your network at once. With IPv4 class-based IP addressing, you can easily determine the broadcast address using your host address: the broadcast address has the host part of your address set to 255. The network part remains untouched. So the broadcast address for the host address 192.168.1.72 is 192.168.1.255 (you combine the network part of the address with 255 in the host part). For CIDR IP addressing, you need to know the number of bits in the netmask. The remaining bits are set to 1 (see Figure 19-3). For example, an IP address of 192.168.4.6/22 has a broadcast address of 192.168.7.255/22. In this case, the first 22 bits are the network address and the last 10 bits are the host part set to the broadcast value (all 1s).

In fact, you can think of a class C broadcast address as merely a CIDR address using 24 bits (the first three segments) for the network address, and the last 8 bits (the fourth segment) as the broadcast address. The value 255 expressed in binary terms is simply 8 bits that are all 1s. 255 is the same as 11111111.

IP Address

Broadcast Address

IP Broadcast Number

Binary Equivalent

192.168.1.72

192.168.1.255

255

11111111

192.168.4.6/22

192.168.7.255/22

7.255 (last 2 bits in 7)

1111111111

Gateway Addresses

Some networks have a computer designated as the gateway to other networks. Every connection to and from a network to other networks passes through this gateway computer. Most local networks use gateways to establish a connection to the Internet. If you are on this type of network, you must provide the gateway address. If your network does not have a connection to the Internet, or a larger network, you may not need a gateway address. The gateway address is the address of the host system providing the gateway service to the network. On many networks, this host is given a host ID of 1: the gateway address for a network with the address 192.168.1 would be 192.168.1.1, but this is only a convention. To be sure of your gateway address, ask your network administrator.

Name Server Addresses

Many networks, including the Internet, have computers that provide a Domain Name Service (DNS) that translates the domain names of networks and hosts into IP addresses. These are known as the network’s domain name servers. The DNS makes your computer identifiable on a network, using only your domain name, rather than your IP address. You can also use the domain names of other systems to reference them, so you needn’t know their IP addresses. You must know the IP addresses of any domain name servers for your network, however. You can obtain the addresses from your system administrator (often more than one exists). Even if you are using an ISP, you must know the address of the domain nameservers your ISP operates for the Internet.

 IPv6 Addressing

IPv6 addresses introduce major changes to the format and method of addressing systems under the Internet Protocol (see RFC 3513 at www.ietf.org/rfc or www.faqs.org for more details). There are several different kinds of addressing with different fields for the network segment. The host segment has been expanded to a 619-bit address, allowing direct addressing for a far larger number of systems. Each address begins with a type field specifying the kind of address, which will then determine how its network segment is organized. These changes are designed not only to expand the address space but to also provide greater control over transmissions at the address level.

Note: Red Hat Enterprise Linux and Fedora are distributed with IPv6 support already enabled in the kernel. Kernel support for IPv6 is provided by the IPv6 kernel module. Kernel configuration support can be found under Device Drivers | Networking Support | Networking Options | The IPv6 Protocol.

 IPv6 Address Format

An IPv6 address consists of 128 bits, up from the 32 bits used in IPv4 addresses. The first 64 bits are used for network addressing, of which the first few bits are reserved for indicating the address type. The last 64 bits are used for the interface address, known as the interface identifier field. The amount of bits used for subnetting can be adjusted with a CIDR mask, much like that in IPv4 CIDR addressing (see the preceding section).

An IPv6 address is written as eight segments representing 16 bits each (128 bits total). To more easily represent 16-bit binary numbers, hexadecimal numbers are used. Hexadecimal numbers use 16 unique numbers, instead of the 8 used in octal numbering. These are 0–9, continuing with the characters A–F.

In the following example, the first four segments represent the network part of the IPv6 address, and the following four segments represent the interface (host) address:

FC00:0000:0000:0000:0008:0800:200C:417A

You can cut any preceding zeros, but not trailing zeros, in any given segment. Segments with all zeros can be reduced to a single zero.

FC00:0:0:0:8:800:200C:417A

The loopback address used for localhost addressing can be written with seven preceding zeros and a 1.

0:0:0:0:0:0:0:1

Many addresses will have sequences of zeros. IPv6 supports a shorthand symbol for representing a sequence of several zeros in adjacent fields. This consists of a double colon (::). There can be only one use of the :: symbol per address.

FC00::8:800:200C:417A

The loopback address 0000000000000001 can be reduced to just the following:

::1

To ease the transition from IPv4 addressing to IPv6, a form of addressing incorporating IPv4 addresses is also supported. In this case, the IPv4 address (32 bits) can be used to represent the last two segments of an IPv6 address and can be written using IPv4 notation.

FC00::192.168.0.3

 IPv6 Interface Identifiers

The identifier part of the IPv6 address takes up the second 64 bits, consisting of four segments containing four hexadecimal numbers. The interface ID is a 619-bit (four-segment) Extended Unique Identifier (EUI-64) generated from a network device’s Media Access Control (MAC) address.

 IPv6 Address types

There are three basic kinds of IPv6 addresses, unicast, multicast, and anycast.

A unicast address is used for a packet that is sent to a single destination.

An anycast address is used for a packet that can be sent to more than one destination.

A multicast address is used to broadcast a packet to a range of destinations.

In IPv6, addressing is controlled by the format prefix that operates as a kind of address type. The format prefix is the first field of the IP address. The three major kinds of unicast network addresses are global, link-local, and unique-local. Global, unique-local, and link-local are indicated by their own format prefix (see Table 19-5).

IPv6 Addresses Format Prefixes and Reserved Addresses

Description

3

Unicast global addresses

FE8

Unicast link-local addresses, used for physically connected hosts on a network, used for DHCP equivalents.

FC00

Unicast unique-local addresses, comparable to IPv4 private addresses.

0000000000000001

Unicast loopback address (for system self-communication, localhost)

0000000000000000

Unspecified address

FF

Multicast addresses

Table 19-5: IPv6 Format Prefixes and Reserved Addresses

Global addresses begin with the address type 3, unique-local with FE00, and link-local with FE8. Global addresses can be sent across the Internet.

Link-local addresses are used for physically connected systems on a local network. It is often used for DHCP addresses.

Unique-local can be used for any hosts on a local network. Unique-local addresses operate like IPv4 private addresses; they are used only for local access and cannot be used to transmit over the Internet.

In addition, IPv6 has two special reserved addresses. The address 0000000000000001 is reserved for the loopback address used for a system's localhost address, and the address 0000000000000000 is the unspecified address.

IPv6 Unicast Global Addresses

IPv6 global addresses currently use four fields: the format prefix, a global routing prefix, the subnet identifier, and the interface identifier. The format prefix for a unicast global address is 3 (3 bits). The global routing prefix references the network address (45 bits), and the subnet ID references a subnet within the site (16 bits).

 IPv6 Unicast Local Use Addresses: Link-Local and Unique-Local Addresses

For local use, IPv6 provides both link-local and unique-local addresses. Link-local addressing is used for interfaces (hosts) that are physically connected to a network. This is usually a small local network. A link-local address uses only three fields, the format prefix FE8 (10 bits), an empty field (54 bits), and the interface identifier (host address) (64 bits). In effect, the network section is empty.

IPv6 unique-local addresses have three fields: the format prefix (10 bits), the subnet identifier (54 bits), and the interface identifier (64 bits). Except for any local subnetting, there is no network address. The unique local address has a format prefix of FC00. The unique-local addresses (also known as unique local addresses) fulfill the same function as private addresses in IPv4 (192.168.0).

 IPv6 Multicast Addresses

Multicast addresses have a format prefix of FF (8 bits) with flag and scope fields to indicate whether the multicast group is permanent or temporary and whether it is local or global in scope. A group identifier (112 bits) references the multicast group. For the scope, 2 is link-local, 5 is unique-local, and E is global. In addition to their interface identifiers, hosts will also have a group ID that can be used as a broadcast address. You use this address to broadcast to the hosts. The following example will broadcast only to those hosts on the local network (5) with the group ID 101:

FF05:0:0:0:0:0:0:101

To broadcast to all the hosts in a link-local scope, you would use the broadcast address:

FF02:0:0:0:0:0:0:1

For a unique-local scope, a local network, you would use

FF05:0:0:0:0:0:0:2

 IPv6 and IPv4 Coexistence Methods

In the transition from IPv4 to IPv6, many networks will find the need to support both. Some will be connected to networks that use the contrary protocol, and others will connect through other network connections that use that protocol. There are several official IETF methods for providing IPv6 and IPv4 cooperation, which fall into three main categories:

Dual-stack Allows IPv4 and IPv6 to coexist on the same networks.

Translation Enables IPv6 devices to communicate with IPv4 devices.

Tunneling: Allows transmission from one IPv6 network to another through IPv4 networks as well as allowing IPv6 hosts to operate on or through IPv4 networks.

In the dual-stack methods, both IPv6 and IPv4 addresses are supported on the network. Applications and DNS servers can use either to transmit data.

Translation uses NAT tables to translate IPv6 addresses to corresponding IPv4 address and vice versa as needed. IPv4 applications can then freely interact with IPv6 applications. IPv6-to-IPv6 transmissions are passed directly through, enabling full IPv6 functionality.

Tunneling is used when one IPv6 network needs to transmit to another through an IPv4 network that cannot handle IPv6 addresses. With tunneling, the IPv6 packet is encapsulated within an IPv4 packet, where the IPv4 network then uses the outer IPv4 addressing to pass on the packet. Several methods are used for tunneling, as shown here, as well as direct manual manipulation:

6-over-4 Used within a network to use IPv4 multicasting to implement a virtual LAN to support IPv6 hosts, without an IPv6 router (RFC 2529)

6-to-4 Used to allow IPv6 networks to connect to and through a larger IPv4 network (the Internet), using the IPv4 network address as an IPv6 network prefix (RFC 3056)

Tunnel brokers Web-based services that create tunnels (RFC 3053)

 TCP/IP Configuration Files

A set of configuration files in the /etc directory, shown in Table 19-6, are used to set up and manage your TCP/IP network. These configuration files specify such network information as host and domain names, IP addresses, and interface options. The IP addresses and domain names of other Internet hosts you want to access are entered in these files. If you configured your network during installation, you can already find that information in these files.

 Identifying Hostnames: /etc/hosts

Without the unique IP address the TCP/IP network uses to identify computers, a particular computer cannot be located. Because IP addresses are difficult to use or remember, domain names are used instead. For each IP address, a domain name exists. When you use a domain name to reference a computer on the network, your system translates it into its associated IP address. This address can then be used by your network to locate that computer.

Address

Description

Host address

IP address of your system; it has a network part to identify the network you are on and a host part to identify your own system

Network address

IP address of your network

Broadcast address

IP address for sending messages to all hosts on your network at once

Gateway address

IP address of your gateway system, if you have one (usually the network part of your host IP address with the host part set to 1)

Domain name server addresses

IP addresses of domain name servers your network use

Netmask

Used to determine the network and host parts of your IP address

File

Description

/etc/hostname

Computer's hostname

/etc/hosts

Associates hostnames with IP addresses, lists domain names for remote hosts with their IP addresses

/etc/sysconfig/network-scripts

Network connection configurations

/etc/host.conf

Lists resolver options

/etc/nsswitch.conf

Name Switch Service configuration

/etc/resolv.conf

Lists domain name server names, IP addresses (nameserver), and domain names where remote hosts may be located (search)

/etc/protocols

Lists protocols available on your system

/etc/services

Lists available network services, such as FTP and Telnet, and the ports they use

/etc/sysconfig/network

Network configuration information

Table 19-6: TCP/IP Configuration Addresses and Files

Originally, every computer on the network was responsible for maintaining a list of the hostnames and their IP addresses. This list is still kept in the /etc/hosts file. When you use a domain name, your system looks up its IP address in the hosts file. The system administrator is responsible for maintaining this list. Because of the explosive growth of the Internet and the development of larger networks, the responsibility for associating domain names and IP addresses has been taken over by domain name servers. The hosts file is still used to hold the domain names and IP addresses of frequently accessed hosts, however. Your system normally checks your hosts file for the IP address of a domain name before taking the added step of accessing a name server.

The format of a domain name entry in the hosts file is the IP address followed by the domain name, separated by a space. You can then add aliases for the hostname. After the entry, on the same line, you can enter a comment. A comment is always preceded by a # symbol. You can already find an entry in your hosts file for localhost.localdomain and localhost with the IP address 127.0.0.1; localhost is a special identification used by your computer to enable users on your system to communicate locally with each other. The IP address 127.0.0.1 is a special reserved address used by every computer for this purpose. It identifies what is technically referred to as a loopback device. The corresponding IPV6 localhost address is ::1 which has the hostname localhost6. You should never remove the localhost and localhost6 entries. A sample /etc/hosts file is shown here:

/etc/hosts

127.0.0.1           localhost.localdomain localhost turtle.mytrek.com
::1                 localhost6.localdomain6  localhost6
192.168.0.1         turtle.mytrek.com
192.168.0.2         rabbit.mytrek.com
192.168.34.56       pango1.mytrain.com

/etc/resolv.conf

The /etc/resolv.conf file holds the IP addresses for your DNS servers along with domains to search. A DNS entry will begin with the term nameserver followed by the name server’s IP address. A search entry will list network domain addresses. Check this file to see if your network DNS servers have been correctly listed. An example is shown here.

/etc/resolv.conf

search  mytrek.com   mytrain.com
nameserver  192.168.0.1

For DHCP connections, the resolv.conf file is a link to the /run/resolvconf/resolv.conf file, which holds the DNS server and search domains provided by the DHCP server. 

/etc/sysconfig/network-scripts

The /etc/sysconfig/network-scripts directory holds configuration information for different network connection devices such the IP address and network address used. For a detailed discussion, see the section “Network Interfaces and Routes: ifconfig and route” later in this chapter.

/etc/services

The /etc/services file lists network services available on your system, such as FTP and Telnet, and associates each with a particular port. Here, you can find out what port your Web server is checking or what port is used for your FTP server. You can give a service an alias, which you specify after the port number. You can then reference the service using the alias.

/etc/protocols

The /etc/protocols file lists the TCP/IP protocols currently supported by your system. Each entry shows the protocol number, its keyword identifier, and a brief description. See www.iana.org/assignments/protocol-numbers for a complete listing.

/etc/sysconfig/network

The /etc/sysconfig/network file contains networking options for your network configuration.

NETWORKING=yes

/etc/hostname and hostnamectl

The /etc/hostname file contains your hostname.  You can use the hostnamectl command to display your current hostname and all information pertaining to it such as the machine ID, the kernel used, the architecture, chassis (type of computer), and the operating system (you can add the status option if you want). Three different kinds of hostnames are supported: static, pretty, and transient. You can set each with the hostnamectl's set-hostname command with the corresponding type. The static hostname is used to identify your computer on the network (usually a fully qualified host name). You can use the --static option to set it. The pretty hostname is a descriptive hostname made available to users on the computer. This can be set by set-hostname with the --pretty option. The transient hostname is one allocated by a network service such as DHCP, and can be managed with the --transient option. Without options, the set-hostname command will apply the name to all the host name types.

hostnamectl set-hostname --pretty "my computer"

The set-chassis command sets the computer type, which can be desktop, laptop, server, tablet, handset, and vm (virtual system). Without a type specified it reverts to the default for the system. The set-icon-name sets the name used by the graphical applications for the host.

Domain Name System (DNS)

Each computer connected to a TCP/IP network, such as the Internet, is identified by its own IP address. IP addresses are difficult to remember, so a domain name version of each IP address is also used to identify a host. A domain name consists of two parts, the hostname and the domain. The hostname is the computer’s specific name, and the domain identifies the network of which the computer is a part. The domains used for the United States usually have extensions that identify the type of host. For example, .edu is used for educational institutions and .com is used for businesses. International domains usually have extensions that indicate the country they are located in, such as .fr for France or .au for Australia. The combination of a hostname, domain, and extension forms a unique name by which a computer can be referenced. The domain can, in turn, be split into further subdomains.

As you know, a computer on a network can still be identified only by its IP address, even if it has a hostname. You can use a hostname to reference a computer on a network, but this involves using the hostname to look up the corresponding IP address in a database. The network then uses the IP address, not the hostname, to access the computer. Before the advent of large TCP/IP networks, such as the Internet, it was feasible for each computer on a network to maintain a file with a list of all the hostnames and IP addresses of the computers connected on its network. Whenever a hostname was used, it was looked up in this file and the corresponding IP address was located. You can still do this on your own system for remote systems you access frequently.

As networks became larger, it became impractical—and, in the case of the Internet, impossible—for each computer to maintain its own list of all the domain names and IP addresses. To provide the service of translating domain addresses to IP addresses, databases of domain names were developed and placed on their own servers. To find the IP address of a domain name, you send a query to a name server, which then looks up the IP address for you and sends it back. In a large network, several name servers can cover different parts of the network. If a name server cannot find a particular IP address, it sends the query on to another name server that is more likely to have it.

If you are administering a network and you need to set up a name server for it, you can configure a Linux system to operate as a name server. To do so, you must start up a name server daemon and then wait for domain name queries. A name server makes use of several configuration files that enable it to answer requests. The name server software used on Linux systems is the Berkeley Internet Name Domain (BIND) server distributed by the Internet Software Consortium (https://www.isc.org/). Chapter 30 describes the process of setting up a domain name server in detail.

Name servers are queried by resolvers. These are programs specially designed to obtain addresses from name servers. To use domain names on your system, you must configure your own resolver. Your local resolver is configured with your /etc/host.conf and /etc/resolv.conf files. You can use /etc/nsswitch in place of /etc/host.conf.

host.conf

Your host.conf file lists resolver options (shown in Table 19-7). Each option can have several fields, separated by spaces or tabs. You can use a # at the beginning of a line to enter a comment. The options tell the resolver what services to use. The order of the list is important. The resolver begins with the first option listed and moves on to the next ones in turn. You can find the host.conf file in your /etc directory, along with other configuration files.

Option

Description

order

Specifies sequence of name resolution methods:
hosts Checks for name in the local /etc/host file
bind Queries a DNS name server for an address
nis Uses Network Information Service protocol to obtain an address

alert

Checks addresses of remote sites attempting to access your system; you turn it on or off with the on and off options

nospoof

Confirms addresses of remote sites attempting to access your system

trim

Checks your local host’s file; removes the domain name and checks only for the hostname; enables you to use only a hostname in your host file for an IP address

multi

Checks your local hosts file; allows a host to have several IP addresses; you turn it on or off with the on and off options

Table 19-7: Resolver Options, host.conf

In the next example of a host.conf file, the order option instructs your resolver first to look up names in your local /etc/hosts file, and then, if that fails, to query domain name servers. The system does not have multiple addresses.

/etc/host.conf

# host.conf file
# There are multiple addresses
multi on
# Lookup names in host file and then check DNS
order bind host

/etc/nsswitch.conf: Name Service Switch and authselect

Different functions in the standard C Library must be configured to operate on your Linux system. Previously, database-like services, such as password support and name services like NIS or DNS, directly accessed these functions, using a fixed search order. For GNU C Library 2.x, used on current versions of Linux, this configuration is carried out by a scheme called the Name Service Switch (NSS), which is based on the method of the same name used by Sun Microsystems Solaris 2 OS. The database sources and their lookup order are listed in the /etc/nsswitch.conf file.

File

Description

aliases

Mail aliases, used by Sendmail

ethers

Ethernet numbers

group

Groups of users

hosts

Hostnames and numbers

netgroup

Network-wide list of hosts and users, used for access rules; C libraries before glibc 2.1 only support netgroups over NIS

network

Network names and numbers

passwd

User passwords

protocols

Network protocols

publickey

Public and secret keys for SecureRPC used by NFS and NIS+

rpc

Remote procedure call names and numbers

services

Network services

shadow

Shadow user passwords

Table 19-8: NSS-Supported Files

The /etc/nsswitch.conf file is managed by the authselect tool. You do not edit it directly. Instead you can use the authselect tool to enable or disable features, as well as choose different profiles. Two profiles are provided, SSSD and Winbind. For Fedora, the SSSD profile is used. Features you can choose include with-smartcard, with fingerprint, and with-krb5. Use the select command to specify the profile and the enable-feature option to enable a feature.

sudo authselect select sssd
sudo authselect enable-feature fingerprint

To see a list of possible profiles use the authselect command and the list option. To see information about the current profile use the current option.

sudo authselect list

The profile in use is located at the /etc/authselect/custom directory, with the configuration files for authentication, including nsswitch.conf, system-auth, and password-auth. The two profiles provided for authselect are located in the /usr/share/authselect/default directory. Here there are directories for sssd and winbind. To create a new profile, create a profile directory in the /etc/authselect/custom directory. You could copy the configuration files from a default profile, and then edit the new ones. The authselect tool is a replacement for authconfig and is a much simpler and more effective method for controlling access. See the man page for authselect-migration and authselect-profiles for information about authselect features and profiles.

The /etc/nsswitch.conf file holds entries for the different configuration files that can be controlled by NSS. The system configuration files that NSS supports are listed in Table 19-8. An entry consists of two fields: the service and the configuration specification. The service consists of the configuration file followed by a colon. The second field is the configuration specification for that file, which holds instructions on how the lookup procedure will work. The configuration specification can contain service specifications and action items. Service specifications are the services to search. Currently, valid service specifications are nis, nis-plus, sss, files, db, dns, and compat (see Table 19-9). Not all are valid for each configuration file. For example, the dns service is valid only for the hosts file, whereas nis is valid for all files. The following example will first check SSSD and then the local /etc/password file.

passwd:  sss files

An action item specifies the action to take for a specific service. An action item is placed within brackets after a service. A configuration specification can list several services, each with its own action item. In the following example, the entry for the network file has a configuration specification that says to check the NIS service and, if not found, to check the /etc/protocols file:

bootparams: nisplus [NOTFOUND=return] files

An action item consists of a status and an action. The status holds a possible result of a service lookup, and the action is the action to take if the status is true. Currently, the possible status values are SUCCESS, NOTFOUND, UNAVAIL, and TRYAGAIN (service temporarily unavailable). The possible actions are return and continue: return stops the lookup process for the configuration file, whereas continue continues on to the next listed service. In the preceding example, if the record is not found in NIS, the lookup process ends.

Service

Description

files

Checks corresponding /etc file for the configuration (for example, /etc/hosts for hosts); this service is valid for all files

db

Checks corresponding /var/db databases for the configuration; valid for all files except netgroup

compat

Valid only for passwd, group, and shadow files

dns

Checks the DNS service; valid only for hosts file

sss

Checks the SSSD service; valid for all files

nis

Checks the NIS service; valid for all files

nisplus

NIS version 3

hesiod

Uses Hesiod for lookup

sss

Checks the SSSD service (System Security Service Daemon to manage remote files and folders)

Table 19-9: NSS Configuration Services

Shown here is a copy of the /etc/nsswitch.conf file, which lists commonly used entries. Comments and commented-out entries begin with a # sign:

/etc/nsswitch.conf

#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file.
passwd:     sss files
group:      sss files
netgroup:   sss files
automount:  sss files
services:   sss files
sudoers:    files

shadow:     files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
hosts:      files dns myhostname

aliases:    files nisplus
bootparams: nisplus [NOTFOUND=return] files
publickey:  nisplus

Network Interfaces and Routes: ifconfig and route

Your connection to a network is made by your system through a particular hardware interface, such as an Ethernet card or a modem. Data passing through this interface is then routed to your network. The ifconfig command configures your network interfaces, and the route command sets up network connections accordingly. If you configure an interface with a network configuration tool, such as system-config-network, you needn’t use ifconfig or route. However, you can directly configure interfaces using ifconfig and route, if you want. Every time you start your system, the network interfaces and their routes must be established. This is done automatically for you when you boot up by ifconfig and route commands executed for each interface. If you are manually adding your own interfaces, you must set up the network script to perform the ifconfig and route operations for your new interfaces.

 Network systemd unit file: network.target

Your network interface is started up using the special systemd target file, network.target. This target will activate the NetworkManager.service unit file which invoked NetworkManager to start up your network. You can manually shut down and start your network interface using the systemctl command and the restart, start, or stop options, as well as cockpit. The following commands shut down and then start up your network interface:

sudo systemctl stop network
sudo systemctl start network

If you are changing network configuration, you will have to restart your network interface for the changes to take effect:

service network restart

To test if your interface is working, use the ping command with an IP address of a system on your network, such as your gateway machine. The ping command continually repeats until you stop it with a ctrl-c.

ping 192.168.0.1

Interface Configuration Scripts: /etc/sysconfig/network-scripts

NetworkManager performs the startup operations by executing several specialized scripts located in the /etc/sysconfig/network-scripts directory. The network script uses a script in that directory called ifup to activate a network connection, and ifdown to shut it down; ifup and ifdown will invoke other scripts tailored to the kind of device being worked on, such as ifup-ppp for modems using the PPP protocol, or ifup-ipv6 for network devices that use IP Protocol version 6 addressing.

The ifup and ifdown scripts make use of interface configuration files that bear the names of the network interfaces currently configured, such as ifcfg-enp7s0 for an Ethernet device. These files define shell variables that hold information on the interface, such as whether to start them at boot time. For example, for a static connection, the ifcfg-enp7s0 file would hold definitions for NETWORK, BROADCAST, and IPADDR, which are assigned the network, broadcast, and IP addresses that the device uses.

The ifdown and ifup scripts, in turn, hold the ifconfig and route commands to activate scripts using these variables defined in the interface configuration files. If you want to manually start up an interface with ifup, you simply use the interface configuration file as its argument.

cd /etc/sysconfig/network-scripts
ifup ifcfg-enp7s0

Interface configuration files are automatically generated when you configure your network connections. You can also manually edit these interface configuration files, making changes such as whether to start up the interface at boot or not (though using a configuration tool such as system-config-network is easier). A sample ifcfg-enp7s0 file is shown here using a static IP address:

/etc/sysconfig/network-scripts/ifcfg-enp7s0

NAME=enp7s0
BOOTPROTO=static
BROADCAST=192.168.0.255
IPADDR=192.168.0.1
NETMASK=255.255.255.0
NETWORK=192.168.0.0
ONBOOT=yes

A DHCP-based interface would look something like this, where BOOTPROTO is assigned dhcp:

/etc/sysconfig/network-scripts/ifcfg-enp7s0

NAME=enp7s0
BOOTPROTO=dhcp
HWADDR=00:00:00:00:00:01
TYPE=Ethernet
ONBOOT=yes

ifconfig

The ifconfig command takes as its arguments the name of an interface and an IP address, as well as options. The ifconfig command then assigns the IP address to the interface. Your system now knows that such an interface exists and that it references a particular IP address. In addition, you can specify whether the IP address is a host address or a network address. You can use a domain name for the IP address, provided the domain name is listed along with its IP address in the /etc/hosts file. The syntax for the ifconfig command is as follows:

ifconfig interface -host_net_flag address options

The host_net_flag can be either -host or -net to indicate a host or network IP address. The -host flag is the default. The ifconfig command can have several options, which set different features of the interface, such as the maximum number of bytes it can transfer (mtu) or the broadcast address. The up and down options activate and deactivate the interface. In the next example, the ifconfig command configures an Ethernet interface:

ifconfig enp7s0 192.168.0.1

Option

Description

Interface

Name of the network interface

up

Activates an interface; implied if IP address is specified

down

Deactivates an interface

allmulti

Turns on or off the promiscuous mode; preceding hyphen (-) turns it off; this allows network monitoring

mtu n

Maximum number of bytes that can be sent on this interface per transmission

dstaddr address

Destination IP address on a point-to-point connection

netmask address

IP network mask; preceding hyphen (-) turns it off

broadcast address

Broadcast address; preceding hyphen (-) turns it off

point-to-point address

Point-to-point mode for interface; if address is included, it is assigned to remote system

hw

Sets hardware address of interface

Address

IP address assigned to interface

Table 19-10: The ifconfig Options

For a simple configuration such as this, ifconfig automatically generates a standard broadcast address and netmask. The standard broadcast address is the network address with the number 255 for the host address. For a class C network, the standard netmask is 255.255.255.0, whereas, for a class A network, the standard netmask is 255.0.0.0. If you are connected to a network with a particular netmask and broadcast address, however, you must specify them when you use ifconfig. The option for specifying the broadcast address is broadcast; for the network mask, it is netmask. Table 19-10 lists the different ifconfig options. In the next example, ifconfig includes the netmask and broadcast address:

ifconfig enp7s0 192.168.0.1 broadcast 192.168.0.255 netmask 255.255.255.0

Once you configure your interface, you can use ifconfig with the up option to activate it and with the down option to deactivate it. If you specify an IP address in an ifconfig operation, as in the preceding example, the up option is implied.

ifconfig enp7s0 up

Point-to-point interfaces such as Parallel IP (PLIP), Serial Line IP (SLIP), and Point-to-Point Protocol (PPP) require you to include the pointopoint option. A PLIP interface name is identified with the name plip with an attached number. For example, plip0 is the first PLIP interface. SLIP interfaces use slip0. PPP interfaces start with ppp0. Point-to-point interfaces are those that usually operate between only two hosts, such as two computers connected over a modem. When you specify the pointopoint option, you need to include the IP address of the host. In the next example, a PLIP interface is configured that connects the computer at IP address 192.168.1.72 with one at 204.166.254.14. If domain addresses were listed for these systems in /etc/hosts, those domain names could be used in place of the IP addresses.

ifconfig plip0 192.168.1.72 pointopoint 204.166.254.14

If you need to, you can also use ifconfig to configure your loopback device. The name of the loopback device is lo, and its IP address is the special address 127.0.0.1. The following example shows the configuration:

ifconfig lo 127.0.0.1

The ifconfig command is useful for checking on the status of an interface. If you enter the ifconfig command along with the name of the interface, information about that interface is displayed:

ifconfig enp7s0

To see if your loopback interface is configured, you can use ifconfig with the loopback interface name, lo:

Routing

A packet that is part of a transmission takes a certain route to reach its destination. On a large network, packets are transmitted from one computer to another until the destination computer is reached. The route determines where the process starts and to what computer your system needs to send the packet for it to reach its destination. On small networks, routing may be static—that is, the route from one system to another is fixed. One system knows how to reach another, moving through fixed paths. On larger networks and on the Internet, however, routing is dynamic. Your system knows the first computer to send its packet off to, and then that computer takes the packet from there, passing it on to another computer, which then determines where to pass it on. For dynamic routing, your system needs to know little. Static routing, however, can become complex because you have to keep track of all the network connections.

Your routes are listed in your routing table in the /proc/net/route file. To display the routing table, enter route with no arguments (the netstat -r command will also display the routing table):

$ route
Kernel routing table
Destination Gateway      Genmask      Flags Metric Ref Use  Iface
192.168.0.0    *         255.255.255.0  U     0      0  0    enp7s0
127.0.0.0      *         255.0.2055.0   U     0      0  0    lo
default     192.168.0.1  0.0.0.0        UG    0      0  0    enp7s0

Each entry in the routing table has several fields, providing information such as the route destination and the type of interface used. The different fields are listed in Table 19-11.

With the add argument, you can add routes either for networks with the -net option or with the -host option for IP interfaces (hosts). The -host option is the default. In addition, you can then specify several parameters for information, such as the netmask (netmask), the gateway (gw), the interface device (dev), and the default route (default). If you have more than one IP interface on your system, such as several Ethernet cards, you must specify the name of the interface using the dev parameter. If your network has a gateway host, you use the gw parameter to specify it. If your system is connected to a network, at least one entry should be in your routing table that specifies the default route. This is the route taken by a message packet when no other route entry leads to its destination. The following example is the routing of an Ethernet interface:

route add 192.168.1.2 dev enp7s0

Field

Description

Destination

Destination IP address of the route

Gateway

IP address or hostname of the gateway the route uses; * indicates no gateway is used

Genmask

The netmask for the route

Flags

Type of route: U = up, H = host, G = gateway, D = dynamic, M = modified

Metric

Metric cost of route

Ref

Number of routes that depend on this one

Window

TCP window for AX.25 networks

Use

Number of times used

Iface

Type of interface this route uses

Table 19-11: Routing Entries

If your system has only the single Ethernet device as your IP interface, you could leave out the dev enp7s0 parameter:

route add 192.168.1.2

You can delete any route you establish by invoking ifconfig with the del argument and the IP address of that route, as in this example:

route del 192.168.1.2

For a gateway, you first add a route to the gateway interface and then add a route specifying that it is a gateway. The address of the gateway interface in this example is 192.168.1.1:

route add 192.168.1.1
route add default gw 192.168.1.1

If you are using the gateway to access a subnet, add the network address for that network (in this example, 192.168.23.0):

route add -net 192.168.23.0 gw dev enp7s0

To add another IP address to a different network interface on your system, use the ifconfig and route commands with the new IP address. The following command configures a second Ethernet card (eth1) with the IP address 192.168.1.3:

ifconfig eth1 192.168.1.3
route add 192.168.1.3 dev enp7s0

IP Aliasing

In some cases, you may want to assign a single Linux system that has only one network interface to two or more IP addresses. For example, you may want to run different Web sites that can be accessed with separate IP addresses on this same system. In effect, you are setting up an alias for your system, another address by which it can be accessed. In fact, you are assigning two IP addresses to the same network interface—for example, assigning a single Ethernet card two IP addresses. This procedure, referred to as IP aliasing, is used to set up multiple IP-based virtual hosts for Internet servers. This method enables you to run several Web servers on the same machine using a single interface (or more than one on each of several interfaces). See Chapters 21 and 22 for FTP and Web server information about virtual hosts, and Chapter30 for Domain Name Service configuration.

Setting up an IP alias is a simple matter of configuring a network interface on your system to listen for the added IP address. Your system needs to know what IP addresses it should listen for and on what network interface. You set up IP aliases using the ifconfig and route commands, or a network administrative tool.

To add another address to the same interface, you need to qualify the interface by adding a colon and a number. For example, if you are adding another IP address to and Ethernet device (in this example eth0), you would add a :0 to its interface name, eth0:0. The following example shows the ifconfig and route commands for the Ethernet interface 192.168.1.2 and two IP aliases added to it: 192.168.1.100 and 192.168.1.101. To add yet another IP address to this same interface, you would use eth0:1, incrementing the qualifier, and so on. The first ifconfig command assigns the main IP address, 192.168.1.2, to the first Ethernet device, eth0. Then, two other IP addresses are assigned to that same device. In the first route command, the network route is set up for the Ethernet device, and then routes are set up for each IP interface. The interfaces for the two aliases are indicated with eth0:0 and eth0:1:

ifconfig eth0 192.168.1.2
ifconfig eth0:0 192.168.1.100
ifconfig eth0:1 192.168.1.101
route add -net 192.168.1.0 dev eth0
route add -host 192.168.1.2 dev eth0
route add -host 192.168.1.100 dev eth0:0
route add -host 192.168.1.101 dev eth0:1

IP aliasing must be supported by the kernel before you can use it. If your kernel does not support it, you may have to rebuild the kernel (including IP aliasing support), or use loadable modules to add IP aliasing.

Monitoring Your Network: ping, netstat, tcpdump, EtherApe, Ettercap, Wireshark, and Nagios

Several applications are available on Linux to let you monitor  your network activity. Graphical applications like EtherApe, Ettercap, and Wireshark provide detailed displays and logs to let you analyze and detect network usage patterns. Other tools like ping, netstat, and traceroute offer specific services (see Table 19-12).

Network Information Tools

Description

ping

Detects whether a system is connected to the network.

finger

Obtains information about users on the network.

who

Checks what users are currently online.

whois

Obtains domain information.

host

Obtains network address information about a remote host.

traceroute

Tracks the sequence of computer networks and hosts your message passes through.

wireshark

Protocol analyzer to examine network traffic.

gnome-nettool

GNOME interface for various network tools including ping, finger, and traceroute.

mtr and xmtr

My traceroute combines both ping and traceroute operations (Traceroute on System Tools menu).

EtherApe

Analyze protocol activity

Ettercap

Sniffer program for man-in-middle attacks

netstat

Real time network status monitor

tcpdump

Capture and save network packets

Nagios

Nagios network monitoring, nagios packages

Table 19-12: Network Tools

The EtherApe, Ettercap, and Wireshark tools can be accessed on the Applications | Internet overview. Tools like ping, traceroute, and netstat can be accessed with the Gnome Network Tools application accessible on the Applications overview, Other filter, as well as being run individually on a command line (Terminal window).

EtherApe provides a simple graphical display for your protocol activity. The Preferences dialog lets you set features like the protocol to check and the kind of traffic to report.

GNOME Network Tools: gnome-nettool

For the GNOME desktop, the gnome-nettool utility provides a GNOME interface for entering the ping and traceroute commands (see Figure 19-4), as well as Finger, Whois, and Lookup for querying users and hosts on the network (Other | Network Tools). Whois will provide domain name information about a particular domain, and Lookup will provide both domain name and IP addresses. It also includes network status tools such as netstat and portscan. The first tab, Devices, describes your connected network devices, including configuration and transmission information about each device, such as the hardware address and bytes transmitted. Both IPv4 and IPv6 host IP addresses will be listed.

Figure 19-4: Gnome network tool

Network Information: ping, finger, traceroute, and host

You can use the ping, finger, traceroute, and host commands to find out status information about systems and users on your network. The ping command is used to check if a remote system is up and running. You use finger to find out information about other users on your network, seeing if they are logged in or if they have received mail; host displays address information about a system on your network, giving you a system’s IP and domain name addresses; and traceroute can be used to track the sequence of computer networks and systems your message passed through on its way to you. Table 19-12 lists various network information tools.

ping

The ping command detects whether a system is up and running. ping takes as its argument the name of the system you want to check. If the system you want to check is down, ping issues a timeout message indicating a connection could not be made. The next example checks to see if www.redhat.com is up and connected to the network:

$ ping www.redhat.com
PING www.redhat.com (209.132.177.50) 56(84) bytes of data.
64 bytes from www.redhat.com (209.132.177.50):icmp_seq=1 ttl=118 time=36.7ms
64 bytes from www.redhat.com (209.132.177.50):icmp_seq=2 ttl=118 time=36.9ms
--- www.redhat.com ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3000ms
rtt min/avg/max/mdev = 36.752/37.046/37.476/0.348 ms

You can also use ping with an IP address instead of a domain name. With an IP address, ping can try to detect the remote system directly without having to go through a domain name server to translate the domain name to an IP address. This can be helpful for situations where your network’s domain name server may be temporarily down and you want to check if a particular remote host on your network is connected.

ping 209.132.177.50

Note: A ping operation could also fail if ping access is denied by a network’s firewall.

 finger and who

You can use the finger command to obtain information about other users on your network and the who command to see what users are currently online on your system. The who and w commands list all users currently connected, along with when, how long, and where they logged in. The w command provides more detailed information. It has several options for specifying the level of detail. The who command is meant to operate on a local system or network; finger can operate on large networks, including the Internet, though most systems block it for security reasons.

Note: Wireshark is a protocol analyzer that can capture network packets and display detailed information about them. You can detect what kind of information is being transmitted on your network as well as its source and destination. Wireshark is used primarily for network and server administration.

 host

With the host command, you can find network address information about a remote system connected to your network. This information usually consists of a system’s IP address, domain name address, domain name nicknames, and mail server. This information is obtained from your network’s domain name server. For the Internet, this includes all systems you can connect to over the Internet.

The host command is an effective way to determine a remote site’s IP address or URL. If you have only the IP address of a site, you can use host to find out its domain name. For network administration, an IP address can be helpful for making your own domain name entries in your /etc/host file. That way, you needn’t rely on a remote domain name server (DNS) for locating a site.

$ host gnome.org
gnome.org has address 209.132.180.168
gnome.org mail is handled by 10 smtp.gnome.org.

$ host 209.132.180.168
168.180.132.208.in-addr.arpa domain name pointer proxy2.gnome.org.

traceroute

Internet connections are made through various routes, traveling through a series of interconnected gateway hosts. The path from one system to another could take different routes, some of which may be faster than others. For a slow connection, you can use traceroute to check the route through which you are connected to a host, monitoring the speed and the number of intervening gateway connections a route takes. The traceroute command takes as its argument the hostname or IP addresses for the system whose route you want to check. Options are available for specifying parameters like the type of service (-t) or the source host (-s). The traceroute command will return a list of hosts the route traverses, along with the times for three probes sent to each gateway. Times greater than five seconds are displayed with an asterisk, *.

traceroute rabbit.mytrek.com

You can also use the mtr or xmtr tools to perform both ping and traces (Traceroute on the System Tools menu).

Ettercap

Ettercap is a sniffer program designed to detect Man in the Middle attacks. In this kind of attack, packets are detected and modified in transit to let an unauthorized user access a network. You can use either its graphical interface or its command line interface. Ettercap can perform Unified sniffing on all connections, or Bridged sniffing on a connection between network interfaces. Ettercap uses plugins for specific tasks, like dos_attack to detect Denial of Service attacks and dns-spoof for DNS spoofing detection. Check the plugins Help panel, or enter ettercap -P list for a complete listing. Ettercap can be run in several modes, including a text mode, a command line cursor mode, a script mode using commands in a file, and even as a daemon logging results automatically.

Wireshark

Wireshark is a network protocol analyzer that lets you capture packets transmitted across your network, selecting and examining those from protocols you want to check. You can examine packets from a particular transmission, displaying the data in readable formats. The Wireshark interface displays three panes: a listing of current packets, the protocol tree for the currently selected packet, a display of the selected packets contents. The first pane categorizes entries by time, source, destination, and protocol. There are button headers for each. To sort a set of entries by a particular category, click its header. For example, group entries by protocol, click the Protocol button; for destinations, use the Destination button.

Capture Options

To configure Wireshark, you select the Options entry from the Capture menu. This opens an options window where you can select the network interface to watch. Here you can also select options such as the file to hold your captured information in and a size limit for the capture, along with a filter to screen packets. With the promiscuous mode selected, you can see all network traffic passing through that device, whereas with it off, you will see only those packets destined for that device. You can then click the start button to start Wireshark. To stop and start Wireshark, you select the Stop and Start entries on the Capture menu.

The Capture Files option let you select a file to save your capture in. If no file is selected, then data is simply displayed in the Wireshark window. If you want to keep a continuous running snapshot of your network traffic, you can use ring buffers. These are a series of files that are used to save captured data. When they fill up, the capture begins saving again to the first file, and so on. Check Use multiple files to enable this option.

Display options control whether packets are displayed in real time on the Wireshark window.

Limits let you set a limit for the capture packet size.

Capture filter lets you choose the type of protocol you want to check.

Name resolution enables the display of host and domain names instead of IP addresses, if possible.

 Wireshark Filters

A filter lets you select packets that match specified criteria, such as packets from a particular host. Criteria are specified using expressions supported by the Packet Capture Library and implemented by tcpdump. Wireshark filters use similar expressions as those used by the tcpdump command. Check the tcpdump Man page for detailed descriptions.

You can set up either a Search filter in the Find tab (Edit menu) to search for certain packets, or set up a Capture filter in the Options tab (Capture menu) to select which packets to record. The filter window is the same for both. On the filter window, you can select the protocol you want to search or capture. The Filter name and string will appear in the Properties segment. You can also enter your own string, setting up a new filter of your own. The string must be a filter expression.

To create a new filter, enter the name you want to give it in the Filter Name box. Then in the Filter String box, enter the filter expression, like icmp. Then click New. Your new filter will appear in the list. To change a filter, select it and change its expression in the Filter String box, then click Change.

A filter expression consists of an ID, such as the name or number of host, and a qualifier. Qualifiers come in three types: type, direction, and protocol. The type can reference the host, network, or port. The type qualifiers are host, net, and port. Direction selects either source or destination packets, or both. The source qualifier is src, and the destination, dst. With no destination qualifier, both directions are selected. Protocol lets you specify packets for a certain protocol. Protocols are represented using their lowercase names, such as icmp for ICMP. For example, the expression to list all packets coming in from a particular host would be src host hostname, where hostname is the source host. The following example will display all packets from the 192.168.0.3 host:

src host 192.168.0.3

Using just host will check for all packets going out as well as coming in for that host. The port qualifier will check for packets passing through a particular port. To check for a particular protocol, you use the protocol name. For example, to check for all ICMP packets you would use the expression

icmp

There are also several special qualifiers that let you further control your selection. The gateway qualifier lets you detect packets passing through a gateway. The broadcast and multi-cast qualifiers detect packets broadcast to a network. The greater and less qualifiers can be applied to numbers such as ports or IP addresses.

You can combine expressions into a single complex Boolean expression using and, or, or not. This lets you create a more refined filter. For example, to capture only the ICMP packets coming in from host 192.168.0.2, you can use

src host 192.168.0.3 and icmp

tcpdump

Like Wireshark, tcpdump will capture network packets, saving them in a file where you can examine them. tcpdump operates entirely from the command line. You will have to open a terminal window to run it. Using various options, you can refine your capture, specifying the kinds of packets you want. tcpdump uses a set of options to specify actions you want to take, which include limiting the size of the capture, deciding which file to save it to, and choosing any filter you want to apply to it. Check the tcpdump Man page for a complete listing.

The -i option lets you specify an interface to listen to.

With the -c option, you can limit the number of packets to capture.

Packets will be output to the standard output by default. To save them to a file, you can use the -w option.

You can later read a packet file using the -r option and apply a filter expression to it.

The tcpdump command takes as its argument a filter expression that you can use to refine your capture. Wireshark uses the same filter expressions as tcpdump (see the filters discussion in Wireshark).

netstat

The netstat program provides real-time information on the status of your network connections, as well as network statistics and the routing table. The netstat command has several options you can use to bring up different sorts of information about your network.

$ netstat
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (State) User
tcp 0 0 turtle.mytrek.com:01 pango1.mytrain.com.:ftp ESTABLISHED dylan
Active UNIX domain sockets
Proto RefCnt  Flags      Type            State       Path
unix    1    [ ACC ]    SOCK_STREAM      LISTENING   /dev/printer
unix    2    [ ]        SOCK_STREAM      CONNECTED   /dev/log
unix    1    [ ACC ]    SOCK_STREAM      LISTENING   /dev/nwapi
unix    2    [ ]        SOCK_STREAM      CONNECTED   /dev/log
unix    2    [ ]        SOCK_STREAM      CONNECTED
unix    1    [ ACC ]    SOCK_STREAM      LISTENING   /dev/log

The netstat command with no options lists the network connections on your system. First, active TCP connections are listed, and then the active domain sockets are listed. The domain sockets contain processes used to set up communications among your system and other systems. You can use netstat with the -r option to display the routing table, and netstat with the -i option displays the uses of the different network interfaces.

Nagios

Fedora also supports Nagios, the enterprise level network monitoring software. You can install Nagios with the nagios and nagios-plugins packages. The nagios-plugins-all package will install all plugin packages. You can also choose to install plugins separately, like those for DHCP, DNS, or HTTPD. Configuration files for Nagios are located at /etc/nagios. The main configuration file is nagios.cfg, an editable text file with detailed comments for each directive.

You will have to first create a nagios administration user and password for accessing the Web interface. Open a terminal window and enter the following. You will be prompted to enter a new password twice.  Log in as the root user first, su command.

htpasswd -c /etc/nagios/htpasswd.users nagiosadmin

You then open your browser and access your nagios interface with the following URL.

http://localhost/nagios

You will be prompted to enter a user and password. Use the user nagiosadmin and the password you were prompted to enter when you ran the htpasswd command.

nagiosadmin

Nagios also provides a remote plugin server that allows Nagios plugins to run on remote hosts. The Nagios Remote Plugin Executor server (NRPE) is installed with the nrpe and the nagios-plugins-nrpe packages. The NRPE server script is nrpe. The configuration file for the NRPE server is /etc/nagios/nrpe.cfg.

service nrpe start

Table Listing

Table 1-1: Fedora sites

Table 2-1: Command line interface text editors

Table 2-2: Fedora Network Configuration Tools

Table 2-3: The nmcli objects

Table 2-4: Network Interface Device Naming

Table 3-1: systemd unit types and man pages

Table 3-2: systemd Unit and Install section options (common to all units, systemd.unit)

Table 3-3: special units

Table 3-4: special runlevel targets (boot)

Table 3-5: systemd exec options (Service, Socket, Mount, Swap) (systemd.exec)

Table 3-6: systemd service options [Service] (systemd.service)

Table 3-7: Collection of Service unit files in /lib/systemd/system

Table 3-8: systemd socket file options [Socket] (systemd.socket)

Table 3-9: path option (systemd.path)

Table 3-10: System Runlevels (States)

Table 3-11: systemd mount and automount file options [Mount] [Automount]

Table 3-12: System Shutdown Options

Table 4-1: Network Security Applications

Table 4-2: FirewallD zones

Table 4-3: IPtables Targets

Table 4-4: Netfilter Built-in Chains

Table 4-5: IPtables Commands

Table 4-6: IPtables Options

Table 4-7: Common ICMP Packets

Table 4-8: Fedora IPtables Scripts and Tools

Table 4-9: Configuration Parameters for iptables-config

Table 5-1: BASH Shell Test Operators

Table 5-2: BASH Shell Control Structures

Table 6-1: Mail Transfer Agents

Table 6-2: Sendmail Files and Directories

Table 6-3: Sendmail Features

Table 6-4: Access Actions

Table 7-1: FTP Servers

Table 7-2: Configuration Options for vsftpd.conf

Table 7-3: Files for vsftpd

Table 7-4: ProFTPD Configuration Directives, proftpd.conf

Table 8-1: Web server Websites

Table 8-2: Apache Web Server Files and Directories

Table 8-3: Apache management tools

Table 8-4: Global Directives

Table 8-5: MPM Prefork, Worker, and Event Directives

Table 8-6: Server Directives

Table 8-7: Access Control Directives

Table 8-8: Directory Directives

Table 8-9: CGI Directives

Table 8-10: Indexing Directives

Table 8-11: Logging Directives

Table 8-12: Apache Log Field Specifiers

Table 9-1: Database Resources

Table 9-2: MySQL Commands

Table 10-1: Print Resources

Table 10-2: CUPS Configuration Files

Table 10-3: CUPS Print Clients

Table 10-4: CUPS Administrative Tools

Table 11-1: NFS daemons and systemd unit files

Table 11-2: The /etc/exports Options

Table 11-3: NFS Mount Options

Table 12-1: Samba packages on Fedora

Table 12-2: Samba Applications

Table 12-3: Samba Substitution Variables

Table 13-1: Distributed File Systems

Table 13-2: GFS2 Tools

Table 14-1: Protocols Supported by Squid

Table 14-2: Squid ACL Options

Table 15-1: Non-Internet Private Network IP Addresses

Table 15-2: BIND 9 Diagnostic and Administrative Tools

Table 15-3: DNS BIND Zone Types

Table 15-4: BIND Configuration Statements

Table 15-5: Zone Options

Table 15-6: Bind Options for the options Statement

Table 15-7: Domain Name System Resource Record Types

Table 16-1: DHCP Declarations, Parameters, and Options

Table 17-1: Fedora Configuration Tools

Table 17-2: System Directories

Table 17-3: Configuration Files and Directories

Table 17-4: Performance Tools

Table 17-5: Cron Files and Directories

Table 18-1: Shell Invocation Command Names

Table 18-2: Shell Configuration Files

Table 18-3: BASH Shell Special Features

Table 18-4: Shell Variables, Set by the Shell

Table 18-5: System Environment Variables Used by the Shell

Table 19-1: TCP/IP Protocol Development Groups

Table 19-2: TCP/IP Protocol Suite

Table 19-3: CIDR IPv4 Network Masks

Table 19-4: Non-Internet IPv4 Local Network IP Addresses

Table 19-5: IPv6 Format Prefixes and Reserved Addresses

Table 19-6: TCP/IP Configuration Addresses and Files

Table 19-7: Resolver Options, host.conf

Table 19-8: NSS-Supported Files

Table 19-9: NSS Configuration Services

Table 19-10: The ifconfig Options

Table 19-11: Routing Entries

Table 19-12: Network Tools

Figure Listing

Figure 1-1: Installation, Installation Summary

Figure 1-2: Installation, Software Selection

Figure 1-3: Installation, Configuration

Figure 2-1: Fedora GRUB menu

Figure 2-2: Editing a GRUB menu item

Figure 2-3: Server login

Figure 2-4: Server hostname changed

Figure 2-5: Editing with nano

Figure 2-6: Fedora GNOME desktop

Figure 2-7: GNOME 3 Activities Applications Overview Mode

Figure 2-8: File manager for home folder

Figure 2-9: Network (System Settings)

Figure 2-10: Wireless configuration

Figure 2-11: Wired Configuration

Figure 2-12: GNOME Software

Figure 2-13: Software, PackageKit (Packages)

Figure 2-14: Package information

Figure 2-15: Update notification message and icon

Figure 2-16: Terminal Window

Figure 3-1: Services, cockpit

Figure 4-1: firewall-config: Runtime Configuration

Figure 4-2: firewall-config: Permanent Configuration

Figure 4-3: Default Zone

Figure 4-4: Base Zone Settings

Figure 4-5: Service Settings

Figure 4-6: Service Protocols and Ports

Figure 4-7: Port Forwarding

Figure 4-8: ICMP Filters

Figure 4-9: The system-config-firewall showing Firewall Trusted Services

Figure 4-10: Firewall Other Ports configuration

Figure 4-11: Firewall Trusted Interfaces

Figure 4-12: Firewall Masquerading

Figure 4-13: ICMP Filters

Figure 4-14: Firewall Custom Rules

Figure 4-15: A network with a firewall

Figure 4-16: Firewall rules applied to a local network example

Figure 8-1: system-config-httpd Server Configuration

Figure 8-2: system-config-httpd Performance Tuning

Figure 8-3: system-config-httpd Virtual Hosts

Figure 8-4: system-config-httpd Virtual Hosts Properties, General Options

Figure 8-5: system-config-httpd Virtual Hosts Properties | Performance | Directory

Figure 10-1: GNOME 3 Printers tool

Figure 10-2: system-config-printer tool: multiple printers

Figure 10-3: Printer properties window

Figure 10-4: CUPS Web-based Configuration: Home tab

Figure 12-1: Allowing Samba on Firewall

Figure 12-2: Allowing Samba on SELinux: system-config-selinux

Figure 15-1: DNS server operation

Figure 16-1: Stateless IPv6 address autoconfiguration

Figure 16-2: Router renumbering with IPv6 autoconfiguration

Figure 17-1: GNOME Logs

Figure 19-1: Class based netmask operations

Figure 19-2: CIDR addressing

Figure 19-3: Class based and CIDR broadcast addressing

Figure 19-4: Gnome network tool

Index

A   B   C   D   E   F   G   H   I   K   L   M   N   O   P   Q   R   S   T   U   V   W   X   Z

.bash_logout, link

.bash_profile, link

.bashrc, link

.mount, link

.path, link

.service, link

.socket, link

.target, link, link

/etc, link

/etc/bash_completion.d, link

/etc/bashrc, link

/etc/crontab, link, link

/etc/default/grub, link

/etc/fstab, link

/etc/hostname, link

/etc/hosts, link

/etc/nsswitch.conf, link

/etc/profile, link

/etc/protocols, link

/etc/rc.d/init.d, link

/etc/rc.d/init.d/network, link

/etc/resolv.conf, link

/etc/services, link

/etc/sysconfig, link

/etc/sysconfig/network, link

/etc/sysconfig/network-scripts, link

/etc/systemd/system, link, link

/lib/systemd/system, link, link

A

Access Control Lists, link

addresses

broadcast Addresses, link

Class-Based IP Addressing, link

Classless Interdomain Routing, link

Gateway Addresses, link

IPv4 Reserved Addresses, link

IPv6 Addressing, link

netmask, link

Administration

Logs, link

Administration, link

access, link

configuration riles, link

Fedora System Tools, link

root user account, link

Services, link

su, link, link

Tools, link

CUPS configuration tool, link

Network Manager, link

system-config-printer, link

terminal window, link

text editors, link

Administration

GNOME System Monitor, link

Administration

networks, link

Aliases, link

Amsvisd-new, link

anacron, link

anacrontab, link

anonymous FTP, link

Apache, link, link

authentication, link

configuration, link, link

directory-level configuration, link

installation, link

instances, link

logs, link

MPM, link

multiprocessing modules, link

name-based virtual hosting, link

NGINX, link

PHP, link

server side includes, link

setup-instance, link

SSL, link

system-config-httpd, link

UserDir, link

virtual hosting, link

virtual hosts, link

Apache web server, link

apachectl, link

arptables, link

Authentication

Apache Web server, link

System Security Services Daemon, link

authselect

Name Service Switch, link

autoconfiguration

IPv6, link

Avahi, link

B

Back Quotes, link

BASH_ENV, link

Berkeley Internet Name Domain (BIND), link

bind

TSIG, link

BIND

access control lists, link

configure, link

DHCP, link

DNS, link

DNSSEC, link

internal and external views, link

localhost reverse mapping, link

named, link

named.conf, link

resource records, link

reverse mapping file, link

slave, link

split DNS, link

Start of Authority (SOA) record, link

subdomain, link

view clause, link

views, link

zone, link, link

boot

fstab mount units, link

graphical.target, link

runlevels, link

special targets, link

boot loader

re-install, link

Bootloader

configuration, link

edit, link

GRUB_DEFAULT, link

Broadcast Addresses, link

C

caches

proxy, link

Chains, link

Chrony, link

chrony.conf, link

chroot, link

CIDR, link

cifs, link

ClamAV

Amsvisd-new, link

Class-Based IP Addressing, link

Classless Interdomain Routing, link

clustering

Corosync Cluster Engine, link

GFS, link, link

OCFS2, link

Pacemaker, link

pcs, link

command line, link

date, link

editors, link

Man pages, link

terminal window, link

USB drives, link

commands, link

Common Unix Printing System (CUPS), link

conditional control structures, link

if, link

if-then, link

configuration, link

nano, link

networks, link

system-config-printer, link

text editors, link

configuration files, link

connection tracking, link

Control Structures, link

conditions, link

for-in, link

if, link

if-then, link

Loop, link

test, link

while, link

Corosync Cluster Engine, link

Courier, link

cron, link, link

/etc/crontab, link

anacron, link

crontab, link, link

editing, link

CUPS, link

accept, link

configuration, link

cupdenable, link

cups-browsed.conf, link

cupsctl, link

cupsd.conf, link

cups-files.conf, link

Limit directives, link

Location directives, link

lpadmin, link

lpoptions, link

print clients, link

printers.conf, link

reject, link

remote printers, link

subscription.conf, link

Web vonfiguration interface, link

CUPS configuration tool, link

cups-browsed.conf, link

cupsctl, link

cupsd.conf, link, link

cupsenable, link

cups-files.conf, link

Cyrus IMAP server, link

D

database servers, link

MariaDB, link

PostgreSQL, link

date, link

Date

date, link

desktop, link

Desktop

File Manager, link

DHCP, link

Domain Name System, link

DHCP 4

clients, link

DHCP 6, link

dhcpd.conf, link

Dynamic DNS, link

fixed addresses, link

IPv4, link

IPv4 addressing, link

IPv6, link

IPv6 addressing, link

subnetworks, link

DHCPv6

DHCP 4, link

dnf, link

updating software, link

DNF, link, link

automatic updates, link

dnf-automatic, link

DNS, link

DNS Firewall), link

DNSSEC, link

dnssec-keygen, link

dnssec-lookaside, link

dnssec-signzone, link

dnssec-validation, link

managed-keys-directory, link

resource records, link

trusted-keys, link

validation, link

dnssec-keygen, link

dnssec-lookaside, link

dnssec-signzone, link

dnssec-validation, link

dnvironment variables, link

documentation

Fedora, link

info pages, link

Domain Name System, link, link, link

access control lists, link

BIND, link

chroot, link

configuration, link

configure, link

DHCP, link

DNS Firewal, link

DNSSEC, link

internal and external views, link

IP-based virtual hosting, link

IPv4 Addressing, link

IPv6 Addressing, link

IPv6 private networks, link

localhost reverse mapping, link

named, link

named.conf, link, link

resolv.conf, link

resource records, link

Response Policy Zones (RPZ), link

reverse mapping file, link

security, link

server types, link

slave, link

split DNS, link

Start of Authority (SOA) record, link

subdomain, link

Time To Live, link

TSIG, link

views, link, link

Zone Files, link

Dovecot, link

Dracut

GRUB, link

Dynamic DNS

DHCP 4, link

Dynamic Host Configuration Protocol (DHCP), link

Dynamic IP Address, link

dynamic virtual hosting, link

E

ebtables, link

edit

GRUB 2, link

Editors

nano, link

text editors, link

vi, link

vim, link

enable, link

environment variables, link

Ettercap, link

Exim, link

export, link

exports, link

Extended Internet Services Daemon, link

F

Fedora, link

desktop, link

documentation, link

Introduction, link

logo, link

Fedora 28, link

Fedora System Tools, link

fedoraproject.org, link

File Manager, link

file systems, link

File Transfer Protocol (FTP), link

finger, link

Firewall

arptables, link

ebtables, link

ICMP, link

IP masquerading, link

IP Spoofing, link

ip6tables, link

IPtables, link

masquerading, link, link

Netfilter, link

Network Address Translation, link

Packet Mangling, link

Ports, link, link

services, link

system-config-firewall, link

Trusted interfaces, link

Trusted services, link

vsftpd, link

xtables, link

firewall-config

samba, link

Firewalls

Response Policy Zones (RPZ), link

for-in, link

free, link

Frysk, link

fstab, link, link

FTP, link

anonymous, link

ProFTPD, link

rsync, link

user access, link

Very Secure FTP Server, link

virtual hosts, link

virtual users, link

vsftpd, link

ftpcount, link

ftpshut, link

ftpwho, link

G

Gateway Addresses, link

GFS, link, link

Corosync Cluster Engine, link

Glances, link

Global File System (GFS and GFS 2), link

Global File System (GFS), link

GNOME

File Manager, link

Network Tools, link

GNOME Network, link

GNOME Software, link

GNOME System Monitor, link

Processes, link

gnome-nettool, link

graphical.target, link

greylisting, link

GRUB

/etc/default/grub, link

configuration, link

Dracut, link

grub2-mkconfig, link

grub-set-default, link

initramfs, link

linux, link

re-install, link

GRUB 2

editing, link

GRUB_DEFAULT, link

grub2-mkconfig, link

grub-set-default, link

H

Help

info pages, link

Man pages, link

HOME, link

host, link

host.conf, link

hostname, link

hostnamectl, link

hosts.allow, link

httpd.conf, link

hwclock, link

I

ICMP, link, link

if, link

ifconfig, link

if-then, link

IMAP, link

info, link

initramfs

GRUB, link

inittab, link

INN, link

installing software packages

DNF, link

GNOME Software, link

PackageKit, link

PackageKit, link

rolectl, link

rolekit, link

Server Roles, link

instances, link

Interfaces

network, link

InterNetNews, link

IP Aliasing, link

IP based virtual hosting, link

IP Masquerading, link

IP Spoofing, link

ip6tables, link

IP-based virtual hosting, link

IPtables, link

Chains, link, link

connection tracking, link

ICMP, link, link

IP masquerading, link

IP Spoofing, link

NAT, link

Netfilter, link

Network Address Translation, link

packet mangling, link

scripts, link

IPv4, link, link

DHCP 4, link

IPv4 Addressing, link

IPv4 Reserved Addresses, link

IPv6, link, link, link

addressing, link

Coexistence Methods, link

DHCP 4, link

DHCP6, link

private networks, link

radvd, link

router renumbering, link

unique-local addresses, link

IPv6 Addressing, link, link

IPv6 autoconfiguration, link

K

kernel

GRUB, link

kill, link

ldbsam, link

L

Lighttpd, link

localhost reverse mapping, link

login

logind, link

logind, link

logs

Apache Web server, link

GNOME Logs, link

loop control structures, link

for-in, link

while, link

lpadmin, link

lpc, link, link

lpinfo, link, link

lpoptions, link, link

lpq, link, link

lpr, link, link

lprm, link, link

lpstat, link

M

Mail, link

Amsvisd-new, link

Dovecot, link

IMAP, link

mail filtering, link

Mail Transport Agents, link

POP, link

Postfix, link

Sendmail, link

spam, link

SpamAssassin, link

Mail servers, link

mailer table, link

Man pages, link

managed-keys-directory, link

map file format, link

MariaDB, link, link

manage, link

my.cnf, link

masquerading, link, link

Sendmail, link

master-format map, link

Microsoft Domain Security, link

Monitoring

free, link

glances, link

top, link

vmstat, link

xload, link

Monitoring networks, link

mount, link

cifs, link

NFS, link

Samba, link

mount.cifs, link

MTA, link

MUA, link

my.cnf, link

N

Nagios, link

Name Service Switch, link

name-based virtual hosting, link

named, link

named.conf, link, link

nano, link

NAT, link

NetBIOS, link

Netfilter, link

Netgroups, link

Netmask, link

netstat, link, link

Network Address Translation, link

Network connections, link

Network File System (NFS), link

Network Information, link

Network Information System (NIS), link

network interfaces, link

Network Time Protocol, link

Chrony, link

chrony.conf, link

TOY, link

Universal Time Coordinated, link

UTC, link

Network Tools

Ettercap, link

finger, link

GNOME, link

host, link

nagios, link

netstat, link

ping, link

tcpdump, link

traceroute, link

who, link

Wireshark, link

Networking

broadcast Addresses, link

Class-Based IP Addressing, link

Classless Interdomain Routing, link

configuration Files, link

Domain Name Service, link

Ettercap, link

Gateway Addresses, link

host.conf, link

ifconfig, link

IPv4 Reserved Addresses, link

IPv6 Addressing, link

link files, link

netmask, link

nmcli, link

predictable network device names, link

renaming device names, link

renaming network device names, link

systemd-networkd, link, link

udev, link

wireshark, link

Zeroconf, link

NetworkManager, link

device names, link

GNOME Network, link

manual configuration, link

nmcli, link

udev, link

NetworkManager Command Line Interface (nmcli), link

Networks

administration, link

Avahi, link

configuration, link

device names, link

GNOME Network, link

IP aliasing, link

IPv4, link

IPv6, link

manual configuration, link

monitoring, link

Ettercap, link

nagios, link

netstat, link

tcpdump, link

wireshark, link

network interfaces, link

NetworkManager, link

nmcli, link

renaming device names, link

renaming network device names, link

routes, link

routing, link

systemd link files, link

TCP/IP, link

udev, link

Zero Configuration Networking, link

News servers, link

Newsgroup, link

NFS, link

/etc/exports, link

fstab, link

hosts.allow, link

mount, link

options, link

portmapper, link

nfslink

nfs4_getfacl, link

nfs4_getfacl, link

NGINX, link

NIS

Clients, link

database, link

netgroups, link

nsswitch.conf, link

NIS server, link

options, link

nmcli, link

NNTPSERVER, link

notify, link

nsswitch.conf, link

O

OCFS2, link

Oracle Cluster File System for Linux, link

P

Pacemaker, link

Pacemaker Configuration System, link

PackageKit, link

browsing, link

categories, link

install, link

Packet Mangling, link

passwd, link

PATH, link

pcs, link

pdbedit, link, link

PDC, link

logon configuration, link

Master Browser configuration, link

PHP, link

ping, link

POP, link

portmapper, link, link

Ports

firewall, link, link

Postfix, link, link

configuration, link

greylisting, link

virtual domains, link

PostgreSQL, link, link

poweroff, link

predictable network device names, link, link

link files, link

systemd-networkd, link

udev, link

print servers

configuration, link

CUPS, link

CUPS configuration tool, link

cupsd.conf, link, link

lpadmin, link

Print services, link

printers.conf, link

Printing

configuration, link

configuration files, link

CUPS, link

lpc, link

lpq, link

lpr, link

lprm, link

lpstat, link

Samba, link

Samba printer, link

system-config-printer, link

Universal Resource Identifier (URI), link

Web vonfiguration interface, link

private networks

IPv4 Reserved Addresses, link

processes, link

GNOME System Monitor, link

kill, link

ps, link

profile, link

proftpd, link

ProFTPD, link

ftpcount, link

ftpshut, link

ftpwho, link

virtual servers, link

prompt, link

Protocol

TCP/IP, link

Proxy servers, link

Squid, link

ps, link

Public Domain Controller, link

pureftpd, link

Q

quotes

strings, link

R

radvd, link

reee, link

reject

printing, link

remote printers

CUPS, link

system-config-printers, link

rescue, link

resource records, link

Response Policy Zones (RPZ), link

reverse mapping

IPv6, link

reverse mapping file, link

rolectl, link

rolekit, link

root user

su, link

sudo, link

root user account, link

router renumbering, link

routes, link

routing, link

rsync, link

configure, link

runlevels, link

/etc/rc.d/init.d, link

S

Samba, link

cifs, link

clients, link

firewall-config, link

global, link

GNOME, link

homes, link

ldbsam, link

master browser configuration, link

Microsoft Domain Security, link

mount, link

pdbedit, link, link

PDC, link

printer, link

Printers, link

Public Domain Controller, link

shared resources, link, link

shares, link

smb.conf, link

smbclient, link

smbpasswd, link, link

tdbsam, link

testparm, link

user level security, link

variables, link

winbindd, link

Windows, link, link

schedule tasks, link

cron, link

systemd timers, link

scope unit files, link

scripts, link

arguments, link

control structures, link

environment variables, link

Security

arptables, link

ebtables, link

IP masquerading, link

IP Spoofing, link

IPtables, link

xtables, link

Sendmail, link, link

configuring, link

mailer table, link

masquerading, link

security, link

sendmail.cf, link

sendmail.mc, link, link

virtusertable, link, link

Server Message Block (SMB), link

Server Roles, link

server side includes, link

servers

rolekit, link

Server Roles, link

service, link, link

services, link

Services, link

/etc/systemd/system, link

/lib/systemd/system, link, link

execution environment options, link

graphical target, link

mount units, link

path units, link

runlevels, link

service, link

service units, link

socket units, link

systemd, link

target units, link, link

template units, link

unit files, link

Settings

Wi-Fi, link

severs

Mail, link

shared resources

GNOME, link

NFS, link

Samba, link

Windows, link, link

shares, link

Shell

.bash_logout, link

.bash_profile, link

.bashrc, link

aliases, link

back quotes, link

bash_completion.d, link

configuration files, link

environment variables, link, link

evaluation of variables, link

HOME, link

PATH, link

profile, link

prompt, link

quotes, link

script arguments, link

scripts, link

strings, link

system environment variables, link

variables, link, link

Shell configuration, link

Shell initialization, link

Shell Programming

control structures, link

for-in, link

if, link

if-then, link

Loop, link

script arguments, link

strings, link

test, link

variables, link

while, link

Shell Scripts, link

shutdown, link

slice unit files, link, link

smb.conf, link

smbclient, link

smbpasswd, link

Software

automatic updates, link

categories, link

GNOME Software, link

installation, link

installing software packages

DNF, link

PackageKit, link

rolectl, link

rolekit, link

Server Roles, link

updating, link

Software Managers

dnf command, link

spam

Amsvisd-new, link

SpamAssassin, link

split DNS, link

Squid, link

cache, link

client browsers, link

security, link

squid.conf, link

SSL

Apache Web server, link

SSSD, link

authselect, link

Start of Authority (SOA) record, link

Static IP address, link

strings, link

quotes, link

su, link

subdomain, link

subscription.conf, link

subshells, link

sudo, link

sudoers, link

visudo, link

sudoers, link

sysconfig, link

system administration

sudo, link

System Configuration, link

system directories, link

System Security Services Daemon, link

System Tools

GNOME System Monitor, link

System V, link

system-config, link

system-config-firewall, link

system-config-httpd, link

virtual hosts, link

system-config-printer, link

system-config-printers, link

remote printers, link

systemd, link

/etc/systemd/system, link

/lib/systemd/system, link, link

execution enironment options, link

file systems, link

graphical target, link

logind, link

mount units, link

path units, link

runlevels, link

scope units, link

service units, link

slice units, link

socket units, link

special targets, link

systemd timers, link

systemd-networkd, link

target units, link

template units, link

unit files, link

systemd timers, link

systemd-networkd, link

renaming device names, link

T

tabs

terminal window, link

targets

graphical r, link

TCP/IP, link

configuration Files, link

tcpdump, link

tdbsam, link

template unit files, link

terminal window, link

tabs, link

test, link

testparm, link

Time

date, link

hwclock, link

Time To Live, link

top, link

traceroute, link

Trusted interfaces, link

Trusted services, link

trusted-keys, link

TSIG, link

U

udev

predictable network device names, link, link

unique-local addresses, link

units

execution environment, link

fstab, link

mount units, link

paths, link

runlevels, link

scope, link

service, link

slice, link

sockets, link

special targets, link

targets, link

templates, link

unit files, link

Universal Resource Identifier, link

Universal Time Coordinated, link

updates

dnf, link

dnf-automatic, link

USB drives, link

Usenet News service, link

User Datagram Protocol, link

user level security

Samba, link

UserDir, link

UTC, link

V

Variables, link

back auotes, link

definition, link

evaluation, link

strings, link

Very Secure FTP Server, link

vi, link

view clause, link

views, link, link

vim, link

virtual domains, link

virtual hosting, link

Apache Web server, link

DNS, link

dynamic virtual hosting, link

IP address–based, link

name-based virtual hosting, link

virtual hosts

Apache Web server, link

virtusertable, link, link

virus

Amsvisd-new, link

visudo, link

vmstat, link

vsftpd, link, link

access controls, link

authentication, link

firewall, link

user access, link

virtual users, link

W

Web server, link

Apache, link

authentication, link

configuration, link, link

directory-level configuration, link

dynamic virtual hosting, link

Lighttpd, link

logs, link

name-based virtual hosting, link

NGINX, link

PHP, link

server side includes, link

SSL, link

system-config-httpd, link

UserDir, link

virtual hosting, link

virtual hosts, link

Webalizer, link

Webalizer, link

while, link

who, link

Wi-Fi

airplane mode, link

winbindd, link

Windows, link

Samba, link, link

shared resources, link, link

wired

Network (Settings), link

nmcli, link

wireless

nmcli, link

Wi-Fi (Settings), link

Wireshark, link

filters, link

X

xload, link

xtables, link

Z

Zero Configuration Networking, link

Zeroconf, link

Avahi, link

zone, link, link

Zone Files, link

map file format, link