Fixing Double Headers
This commit is contained in:
Brian (bex) Exelbierd
parent
693a8137d0
commit
1ce1738883
41 changed files with 609 additions and 620 deletions
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
:experimental:
|
||||
|
||||
=== We want feedback
|
||||
== We want feedback
|
||||
indexterm:[feedback,contact information for this manual]
|
||||
If you find errors or have suggestions for improvement, we want your advice. Submit a report in Bugzilla against the product `{PRODUCT}` and the component `{BOOKID}`. The following link automatically loads this information for you: {BZURL}.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
:experimental:
|
||||
|
||||
=== We Need Feedback!
|
||||
== We Need Feedback!
|
||||
indexterm:[feedback,contact information for this manual]
|
||||
If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20Documentation&component=system-administrator's-guide[Bugzilla].
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
:experimental:
|
||||
include::en-US/entities.adoc[]
|
||||
|
||||
== Preface
|
||||
= Preface
|
||||
|
||||
The [citetitle]_System Administrator's Guide_ contains information on how to customize the {MAJOROSVER} system to fit your needs. If you are looking for a comprehensive, task-oriented guide for configuring and customizing your system, this is the manual for you.
|
||||
|
||||
|
|
@ -22,12 +22,12 @@ Some of the graphical procedures and menu locations are specific to GNOME, but m
|
|||
====
|
||||
|
||||
[[sect-Preface-Target_Audience]]
|
||||
=== Target Audience
|
||||
== Target Audience
|
||||
|
||||
The [citetitle]_System Administrator's Guide_ assumes you have a basic understanding of the {MAJOROS} operating system. If you need help with the installation of this system, refer to the link:++https://docs.fedoraproject.org/install-guide++[{MAJOROS} Installation Guide].
|
||||
|
||||
[[sect-Preface-Book_Organization]]
|
||||
=== How to Read this Book
|
||||
== How to Read this Book
|
||||
|
||||
This manual is divided into the following main categories:
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ link:++Wayland.html++[The Wayland Display Server]:: This appendix looks at Wayla
|
|||
include::en-US/Feedback.adoc[]
|
||||
|
||||
[[pref-Acknowledgments]]
|
||||
=== Acknowledgments
|
||||
== Acknowledgments
|
||||
|
||||
Certain portions of this text first appeared in the [citetitle]_Red{nbsp}Hat Enterprise{nbsp}Linux{nbsp}7 System Administrator's Guide_, copyright © 2014–{YEAR} Red{nbsp}Hat, Inc., available at link:++https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/index.html++[].
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-RPM]]
|
||||
== RPM
|
||||
= RPM
|
||||
indexterm:[RPM Package Manager,RPM]indexterm:[RPM]indexterm:[packages,RPM]
|
||||
The _RPM Package Manager_ ([application]*RPM*) is an open packaging system that runs on {MAJOROS} as well as other Linux and UNIX systems. Red{nbsp}Hat and the Fedora Project encourage other vendors to use [application]*RPM* for their own products. [application]*RPM* is distributed under the terms of the _GPL_ (_GNU General Public License_).
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ Because [application]*RPM* can make changes to the system itself, performing ope
|
|||
====
|
||||
|
||||
[[s1-rpm-design]]
|
||||
=== RPM Design Goals
|
||||
== RPM Design Goals
|
||||
indexterm:[RPM,design goals]
|
||||
To understand how to use [application]*RPM*, it is helpful to understand the design goals of [application]*RPM*:
|
||||
|
||||
|
|
@ -49,12 +49,12 @@ indexterm:[packages,RPM,pristine sources] Pristine Sources:: A crucial
|
|||
The goal of keeping sources pristine may seem important only for developers, but it results in higher quality software for end users.
|
||||
|
||||
[[s1-rpm-using]]
|
||||
=== Using RPM
|
||||
== Using RPM
|
||||
|
||||
[application]*RPM* has five basic modes of operationindexterm:[RPM,basic modes] (not counting package building): installing, uninstalling, upgrading, querying, and verifying. This section contains an overview of each mode. For complete details and options, try [command]#rpm --help# or see *rpm*(8). Also, see xref:RPM.adoc#s1-rpm-additional-resources[Additional Resources] for more information on [application]*RPM*.
|
||||
|
||||
[[sec-Installing_and_Upgrading]]
|
||||
==== Installing and Upgrading Packages
|
||||
=== Installing and Upgrading Packages
|
||||
indexterm:[RPM,installing]indexterm:[RPM,upgrading]indexterm:[packages,installing RPM]indexterm:[packages,upgrading RPM]indexterm:[RPM,file name]
|
||||
[application]*RPM* packages typically have file names in the following form:
|
||||
|
||||
|
|
@ -126,7 +126,7 @@ warning: tree-1.7.0-3.{PKGOS}.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID
|
|||
See xref:RPM.adoc#s1-check-rpm-sig[Checking Package Signatures] for more information on checking package signatures.
|
||||
|
||||
[[s3-rpm-errors]]
|
||||
===== Replacing Already-Installed Packages
|
||||
==== Replacing Already-Installed Packages
|
||||
indexterm:[RPM,already installed]indexterm:[packages,RPM,already installed]
|
||||
If a package of the same name and version is already installed, the following output is displayed:
|
||||
|
||||
|
|
@ -152,7 +152,7 @@ rpm -Uvh --oldpackage older_package.rpm
|
|||
----
|
||||
|
||||
[[s3-rpm-conflicting-files]]
|
||||
===== Resolving File Conflicts
|
||||
==== Resolving File Conflicts
|
||||
indexterm:[RPM,file conflicts,resolving]indexterm:[RPM,conflicts]indexterm:[packages,RPM,conflict]
|
||||
If you attempt to install a package that contains a file that has already been installed by another package, a conflict message is displayed. To make [application]*RPM* ignore this error, use the [command]#--replacefiles# option:
|
||||
|
||||
|
|
@ -162,7 +162,7 @@ If you attempt to install a package that contains a file that has already been i
|
|||
----
|
||||
|
||||
[[s3-rpm-unresolved-dependency]]
|
||||
===== Satisfying Unresolved Dependencies
|
||||
==== Satisfying Unresolved Dependencies
|
||||
indexterm:[RPM,dependencies]indexterm:[packages,dependencies]indexterm:[RPM,failed dependencies]indexterm:[packages,RPM,failed dependencies]
|
||||
[application]*RPM* packages sometimes depend on other packages, which means that they require other packages to be installed to run properly. If you try to install a package that has an unresolved dependency, a message about a failed dependency is displayed.
|
||||
|
||||
|
|
@ -184,7 +184,7 @@ Although you can *force* [command]#rpm# to install a package that has an unresol
|
|||
====
|
||||
|
||||
[[sec-Configuration_File_Changes]]
|
||||
===== Preserving Changes in Configuration Files
|
||||
==== Preserving Changes in Configuration Files
|
||||
indexterm:[RPM,configuration file changes]indexterm:[packages,RPM,configuration file changes]indexterm:[RPM,configuration file changes,conf.rpmsave]
|
||||
Because [application]*RPM* performs intelligent upgrading of packages with configuration files, you may see the following message:
|
||||
|
||||
|
|
@ -198,7 +198,7 @@ This message means that the changes you made to the configuration file may not b
|
|||
Alternatively, [application]*RPM* may save the package's *new* configuration file as, for example, `pass:attributes[{blank}]_configuration_file.conf_.rpmnew` and leave the configuration file you modified untouched. You should still resolve any conflicts between your modified configuration file and the new one, usually by merging changes from the old one to the new one, for example using the [command]#diff# program.
|
||||
|
||||
[[s2-rpm-uninstalling]]
|
||||
==== Uninstalling Packages
|
||||
=== Uninstalling Packages
|
||||
indexterm:[RPM,uninstalling]indexterm:[packages,removing]indexterm:[packages,RPM,uninstalling]indexterm:[packages,RPM,removing]
|
||||
Uninstalling a package is just as simple as installing one. Type the following command at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -238,7 +238,7 @@ Although you can *force* [command]#rpm# to uninstall a package that has unresolv
|
|||
====
|
||||
|
||||
[[s2-rpm-freshening]]
|
||||
==== Freshening Packages
|
||||
=== Freshening Packages
|
||||
indexterm:[RPM,freshening]indexterm:[packages,RPM,freshening]
|
||||
Freshening is similar to upgrading, except that only installed packages are upgraded. Type the following command at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -259,7 +259,7 @@ Freshening works for single packages or package groups. For example, freshening
|
|||
[application]*RPM* then automatically upgrades only those packages that are already installed.
|
||||
|
||||
[[s2-rpm-querying]]
|
||||
==== Querying Packages
|
||||
=== Querying Packages
|
||||
indexterm:[RPM,querying]indexterm:[packages,RPM,querying]
|
||||
The [application]*RPM* database stores information about all [application]*RPM* packages installed on the system. It is stored in the `/var/lib/rpm/` directory and is used for many things, including querying what packages are installed, what version each package is, and for calculating changes to files in packages since their installation. To query this database, use the [command]#rpm# command with the [option]`-q` (or [option]`--query`) option:
|
||||
|
||||
|
|
@ -278,7 +278,7 @@ tree-1.7.0-3.{PKGOS}.x86_64
|
|||
See the `Package Selection Options` subheading in the *rpm*(8) manual page for a list of options that can be used to further refine or qualify your query. Use options listed below the `Package Query Options` subheading to specify what information to display about the queried packages.
|
||||
|
||||
[[s2-rpm-verifying]]
|
||||
==== Verifying Packages
|
||||
=== Verifying Packages
|
||||
indexterm:[RPM,verifying]indexterm:[packages,RPM,verifying]
|
||||
Verifying a package is comparing information about files on the system installed from a package with the same information from the original package. Among other parameters, verifying compares the file size, MD5 sum, permissions, type, owner, and the group of each file.
|
||||
|
||||
|
|
@ -338,12 +338,12 @@ indexterm:[RPM,verification]
|
|||
If you see any output, use your best judgment to determine if you should remove the package, reinstall it, or fix the problem in another way.
|
||||
|
||||
[[s1-find-verify-rpm]]
|
||||
=== Finding and Verifying RPM Packages
|
||||
== Finding and Verifying RPM Packages
|
||||
indexterm:[RPM,finding and verifying RPM packages]
|
||||
Before using any [application]*RPM* packages, you must know where to find them and be able to verify if you can trust them.
|
||||
|
||||
[[s2-rpm-finding]]
|
||||
==== Finding RPM Packages
|
||||
=== Finding RPM Packages
|
||||
indexterm:[packages,finding Fedora RPM packages]indexterm:[RPM,finding Fedora RPM packages]
|
||||
Although there are many [application]*RPM* repositories on the Internet, for security and compatibility reasons, you should consider installing only official Fedora-provided RPM packages. The following is a list of sources for [application]*RPM* packages:
|
||||
|
||||
|
|
@ -366,7 +366,7 @@ When considering third-party repositories for use with your {MAJOROS} system, pa
|
|||
====
|
||||
|
||||
[[s1-check-rpm-sig]]
|
||||
==== Checking Package Signatures
|
||||
=== Checking Package Signatures
|
||||
indexterm:[RPM,GnuPG]indexterm:[RPM,checking package signatures]indexterm:[GnuPG,checking RPM package signatures]
|
||||
[application]*RPM* packages can be signed using [application]*GNU Privacy Guard* (or [application]*GPG*), which helps you make certain that downloaded packages are trustworthy. [application]*GPG* is a tool for secure communication. With [application]*GPG*, you can authenticate the validity of documents and encrypt or decrypt data.
|
||||
|
||||
|
|
@ -382,7 +382,7 @@ Note that the [application]*DNF* package manager performs automatic checking of
|
|||
[application]*GPG* is installed by default, as well as a set of Red{nbsp}Hat keys for verifying packages. To import additional keys for use with [application]*RPM*, see xref:RPM.adoc#s2-keys-importing[Importing GPG Keys].
|
||||
|
||||
[[s2-keys-importing]]
|
||||
===== Importing GPG Keys
|
||||
==== Importing GPG Keys
|
||||
|
||||
To verify Red Hat packages, a Red{nbsp}Hat [application]*GPG* key needs to be installed. A set of basic keys is installed by default. To view a list of installed keys, execute the following command at a shell prompt:
|
||||
|
||||
|
|
@ -408,7 +408,7 @@ Use the [command]#rpmkeys# command with the [option]`--import` option to install
|
|||
See the link:++https://access.redhat.com/security/team/key/++[Product Signing (GPG) Keys] article on the Red{nbsp}Hat Customer{nbsp}Portal for additional information about Red{nbsp}Hat package-signing practices.
|
||||
|
||||
[[s1-rpm-usage-examples]]
|
||||
=== Common Examples of RPM Usage
|
||||
== Common Examples of RPM Usage
|
||||
indexterm:[RPM,tips]indexterm:[packages,RPM,tips]
|
||||
[application]*RPM* is a useful tool for both managing your system and diagnosing and fixing problems. See the following examples for an overview of some of the most-used options.
|
||||
|
||||
|
|
@ -459,7 +459,7 @@ indexterm:[RPM,querying for file list]indexterm:[packages,obtaining list of file
|
|||
See the *rpm*(8) manual page for more options.
|
||||
|
||||
[[s1-rpm-additional-resources]]
|
||||
=== Additional Resources
|
||||
== Additional Resources
|
||||
indexterm:[RPM,additional resources]
|
||||
[application]*RPM* is a complex utility with many options and methods for querying, installing, upgrading, and removing packages. See the following resources to learn more about [application]*RPM*.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
:experimental:
|
||||
|
||||
[[app-Revision_History]]
|
||||
== Revision History
|
||||
= Revision History
|
||||
|
||||
`1-9`:: Sun Jun 25, 2017, Ryan (t3rm1n4l@fedoraproject.org)
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-Wayland]]
|
||||
== The Wayland Display Server
|
||||
= The Wayland Display Server
|
||||
Wayland is a display server which was (at the time of writing) introduced as the default display server in GNOME. It is said that Wayland will eventually replace X11 as the default display server on Linux and many distributions have begun implementation of Wayland. Wayland is a more modern display server and has a smaller code base currently. Wayland is still under development, and there are still applications and behaviours that don't work as expected, you may find that some applications have not been updated to work properly in Wayland and currently the only way these applications will run is using Xorg instead of Wayland. This includes some legacy system applications and games.
|
||||
|
||||
.Wayland in Fedora
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-Configuring_the_Date_and_Time]]
|
||||
=== Configuring the Date and Time
|
||||
= Configuring the Date and Time
|
||||
|
||||
Modern operating systems distinguish between the following two types of clocks:
|
||||
|
||||
|
|
@ -16,14 +16,14 @@ The system time is always kept in _Coordinated Universal Time_ (*UTC*) and conve
|
|||
{MAJOROSVER} offers three command line tools that can be used to configure and display information about the system date and time: the [command]#timedatectl# utility, which is new in {MAJOROSVER} and is part of `systemd`pass:attributes[{blank}]; the traditional [command]#date# command; and the [command]#hwclock# utility for accessing the hardware clock.
|
||||
|
||||
[[sect-Configuring_the_Date_and_Time-timedatectl]]
|
||||
==== Using the timedatectl Command
|
||||
== Using the timedatectl Command
|
||||
|
||||
The [application]*timedatectl* utility is distributed as part of the `systemd` system and service manager and allows you to review and change the configuration of the system clock. You can use this tool to change the current date and time, set the time zone, or enable automatic synchronization of the system clock with a remote server.
|
||||
|
||||
For information on how to display the current date and time in a custom format, see also xref:Configuring_the_Date_and_Time.adoc#sect-Configuring_the_Date_and_Time-date[Using the date Command].
|
||||
|
||||
[[sect-Configuring_the_Date_and_Time-timedatectl-Display]]
|
||||
===== Displaying the Current Date and Time
|
||||
=== Displaying the Current Date and Time
|
||||
|
||||
To display the current date and time along with detailed information about the configuration of the system and hardware clock, run the [command]#timedatectl# command with no additional command line options:
|
||||
|
||||
|
|
@ -61,7 +61,7 @@ NTP synchronized: no
|
|||
====
|
||||
|
||||
[[sect-Configuring_the_Date_and_Time-timedatectl-Time]]
|
||||
===== Changing the Current Time
|
||||
=== Changing the Current Time
|
||||
|
||||
To change the current time, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ By default, the system is configured to use UTC. To configure your system to mai
|
|||
To configure your system to maintain the clock in the local time, replace _boolean_ with `yes` (or, alternatively, `y`, `true`, `t`, or `1`). To configure the system to use UTC, replace _boolean_ with `no` (or, alternatively, `n`, `false`, `f`, or `0`). The default option is `no`.
|
||||
|
||||
[[sect-Configuring_the_Date_and_Time-timedatectl-Date]]
|
||||
===== Changing the Current Date
|
||||
=== Changing the Current Date
|
||||
|
||||
To change the current date, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -126,7 +126,7 @@ To change the current date to 2 June 2013 and keep the current time (11:26 p.m.)
|
|||
====
|
||||
|
||||
[[sect-Configuring_the_Date_and_Time-timedatectl-Time_Zone]]
|
||||
===== Changing the Time Zone
|
||||
=== Changing the Time Zone
|
||||
|
||||
To list all available time zones, type the following at a shell prompt:
|
||||
|
||||
|
|
@ -172,7 +172,7 @@ To change the time zone to `Europe/Prague`, type as `root`:
|
|||
====
|
||||
|
||||
[[sect-Configuring_the_Date_and_Time-timedatectl-NTP]]
|
||||
===== Synchronizing the System Clock with a Remote Server
|
||||
=== Synchronizing the System Clock with a Remote Server
|
||||
|
||||
As opposed to the manual adjustments described in the previous sections, the [command]#timedatectl# command also allows you to enable automatic synchronization of your system clock with a group of remote servers using the `NTP` protocol. Enabling NTP enables the `chronyd` or `ntpd` service, depending on which of them is installed.
|
||||
|
||||
|
|
@ -201,14 +201,14 @@ The command will fail if an `NTP` service is not installed. See xref:../servers/
|
|||
====
|
||||
|
||||
[[sect-Configuring_the_Date_and_Time-date]]
|
||||
==== Using the date Command
|
||||
== Using the date Command
|
||||
|
||||
The [command]#date# utility is available on all Linux systems and allows you to display and configure the current date and time. It is frequently used in scripts to display detailed information about the system clock in a custom format.
|
||||
|
||||
For information on how to change the time zone or enable automatic synchronization of the system clock with a remote server, see xref:Configuring_the_Date_and_Time.adoc#sect-Configuring_the_Date_and_Time-timedatectl[Using the timedatectl Command].
|
||||
|
||||
[[sect-Configuring_the_Date_and_Time-date-Display]]
|
||||
===== Displaying the Current Date and Time
|
||||
=== Displaying the Current Date and Time
|
||||
|
||||
To display the current date and time, run the [command]#date# command with no additional command line options:
|
||||
|
||||
|
|
@ -282,7 +282,7 @@ To customize the output of the [command]#date# command, type:
|
|||
====
|
||||
|
||||
[[sect-Configuring_the_Date_and_Time-date-Time]]
|
||||
===== Changing the Current Time
|
||||
=== Changing the Current Time
|
||||
|
||||
To change the current time, run the [command]#date# command with the [option]`--set` or [option]`-s` option as `root`:
|
||||
|
||||
|
|
@ -314,7 +314,7 @@ To change the current time to 11:26 p.m., run the following command as `root`:
|
|||
====
|
||||
|
||||
[[sect-Configuring_the_Date_and_Time-date-Date]]
|
||||
===== Changing the Current Date
|
||||
=== Changing the Current Date
|
||||
|
||||
To change the current date, run the [command]#date# command with the [option]`--set` or [option]`-s` option as `root`:
|
||||
|
||||
|
|
@ -341,7 +341,7 @@ To change the current date to 2 June 2013 and keep the current time (11:26 p.m.)
|
|||
====
|
||||
|
||||
[[sect-Configuring_the_Date_and_Time-hwclock]]
|
||||
==== Using the hwclock Command
|
||||
== Using the hwclock Command
|
||||
|
||||
`hwclock` is a utility for accessing the hardware clock, also referred to as the Real Time Clock (RTC). The hardware clock is independent of the operating system you use and works even when the machine is shut down. This utility is used for displaying the time from the hardware clock. `hwclock` also contains facilities for compensating for systematic drift in the hardware clock.
|
||||
|
||||
|
|
@ -360,7 +360,7 @@ Precision Time Protocol (PTP), the kernel automatically synchronizes the hardwar
|
|||
For details about NTP, see xref:../servers/Configuring_NTP_Using_the_chrony_Suite.adoc#ch-Configuring_NTP_Using_the_chrony_Suite[Configuring NTP Using the chrony Suite] and xref:../servers/Configuring_NTP_Using_ntpd.adoc#ch-Configuring_NTP_Using_ntpd[Configuring NTP Using ntpd]. For information about PTP, see xref:../servers/Configuring_PTP_Using_ptp4l.adoc#ch-Configuring_PTP_Using_ptp4l[Configuring PTP Using ptp4l]. For information about setting the hardware clock after executing [application]*ntpdate*, see xref:../servers/Configuring_NTP_Using_ntpd.adoc#s1-Configuring_the_Hardware_Clock_update[Configuring the Hardware Clock Update].
|
||||
|
||||
[[sect2-displaying-time-hwclock]]
|
||||
===== Displaying the Current Date and Time
|
||||
=== Displaying the Current Date and Time
|
||||
|
||||
Running [command]#hwclock# with no command line options as the `root` user returns the date and time in local time to standard output.
|
||||
|
||||
|
|
@ -390,7 +390,7 @@ CEST is a time zone abbreviation and stands for Central European Summer Time.
|
|||
For information on how to change the time zone, see xref:Configuring_the_Date_and_Time.adoc#sect-Configuring_the_Date_and_Time-timedatectl-Time_Zone[Changing the Time Zone].
|
||||
|
||||
[[sect3-changing-date-time-hwclock]]
|
||||
===== Setting the Date and Time
|
||||
=== Setting the Date and Time
|
||||
|
||||
Besides displaying the date and time, you can manually set the hardware clock to a specific time.
|
||||
|
||||
|
|
@ -419,7 +419,7 @@ If you want to set the date and time to a specific value, for example, to "21:17
|
|||
====
|
||||
|
||||
[[sect4-synchronizing-date-time-hwclock]]
|
||||
===== Synchronizing the Date and Time
|
||||
=== Synchronizing the Date and Time
|
||||
|
||||
You can synchronize the hardware clock and the current system time in both directions.
|
||||
|
||||
|
|
@ -459,7 +459,7 @@ To avoid problems with time zone and DST switching, it is recommended to keep th
|
|||
====
|
||||
|
||||
[[sect-Date_and_Time-Resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
|
||||
For more information on how to configure the date and time in {MAJOROSVER}, see the resources listed below.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,14 +3,14 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[chap-Gaining_Privileges]]
|
||||
=== Gaining Privileges
|
||||
= Gaining Privileges
|
||||
|
||||
System administrators, and in some cases users, need to perform certain tasks with administrative access. Accessing the system as the `root` user is potentially dangerous and can lead to widespread damage to the system and data. This chapter covers ways to gain administrative privileges using setuid programs such as [command]#su# and [command]#sudo#. These programs allow specific users to perform tasks which would normally be available only to the `root` user while maintaining a higher level of control and system security.
|
||||
|
||||
See the link:++https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/++[Red{nbsp}Hat Enterprise{nbsp}Linux{nbsp}7 Security Guide] for more information on administrative controls, potential dangers, and ways to prevent data loss resulting from improper use of privileged access.
|
||||
|
||||
[[sect-Gaining_Privileges-The_su_Command]]
|
||||
==== The su Command
|
||||
== The su Command
|
||||
|
||||
When a user executes the [command]#su# command, they are prompted for the `root` password and, after authentication, are given a `root` shell prompt.
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ The `root` user is part of the `wheel` group by default.
|
|||
====
|
||||
|
||||
[[sect-Gaining_Privileges-The_sudo_Command]]
|
||||
==== The sudo Command
|
||||
== The sudo Command
|
||||
|
||||
The [command]#sudo# command offers another approach to giving users administrative access. When trusted users precede an administrative command with [command]#sudo#, they are prompted for *their own* password. Then, when they have been authenticated and assuming that the command is permitted, the administrative command is executed as if they were the `root` user.
|
||||
|
||||
|
|
@ -136,7 +136,7 @@ Opening a new shell as `root` in this or similar fashion gives the attacker admi
|
|||
====
|
||||
|
||||
[[sect-Gaining_Privileges-Additional_Resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
|
||||
While programs allowing users to gain administrative privileges are a potential security risk, security itself is beyond the scope of this particular book. You should therefore refer to the resources listed below for more information regarding security and privileged access.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,12 +3,12 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-Managing_Users_and_Groups]]
|
||||
=== Managing Users and Groups
|
||||
= Managing Users and Groups
|
||||
indexterm:[groups,introducing]indexterm:[users,introducing]indexterm:[users,UID]indexterm:[groups,GID]
|
||||
The control of users and groups is a core element of {MAJOROS} system administration. This chapter explains how to add, manage, and delete users and groups in the graphical user interface and on the command line, and covers advanced topics, such as creating group directories.
|
||||
|
||||
[[s1-users-groups-introduction]]
|
||||
==== Introduction to Users and Groups
|
||||
== Introduction to Users and Groups
|
||||
|
||||
While users can be either people (meaning accounts tied to physical users) or accounts which exist for specific applications to use, groups are logical expressions of organization, tying users together for a common purpose. Users within a group share the same permissions to read, write, or execute files owned by that group.
|
||||
|
||||
|
|
@ -17,7 +17,7 @@ Each user is associated with a unique numerical identification number called a _
|
|||
Additionally, {MAJOROS} supports _access control lists_ (*ACLs*) for files and directories which allow permissions for specific users outside of the owner to be set. For more information about this feature, see the [citetitle]_link:++https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Access_Control_Lists.html++[Access Control Lists]_ chapter of the [citetitle]_link:++https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/index.html++[Red Hat Enterprise Linux 7 System Administrators Guide]_.
|
||||
|
||||
[[s2-users-groups-private-groups]]
|
||||
===== User Private Groups
|
||||
=== User Private Groups
|
||||
indexterm:[groups,user private]indexterm:[user private groups,groups]indexterm:[groups,tools for management of,groupadd]
|
||||
{MAJOROS} uses a _user private group_ (_UPG_) scheme, which makes UNIX groups easier to manage. A user private group is created whenever a new user is added to the system. It has the same name as the user for which it was created and that user is the only member of the user private group.
|
||||
|
||||
|
|
@ -28,7 +28,7 @@ The setting which determines what permissions are applied to a newly created fil
|
|||
A list of all groups is stored in the `/etc/group` configuration file.
|
||||
|
||||
[[s2-users-groups-shadow-utilities]]
|
||||
===== Shadow Passwords
|
||||
=== Shadow Passwords
|
||||
indexterm:[passwords,shadow]indexterm:[shadow passwords,overview of]
|
||||
In environments with multiple users, it is very important to use _shadow passwords_ provided by the [package]*shadow-utils* package to enhance the security of system authentication files. For this reason, the installation program enables shadow passwords by default.
|
||||
|
||||
|
|
@ -51,12 +51,12 @@ Most utilities provided by the [package]*shadow-utils* package work properly whe
|
|||
* The [command]#useradd# command with the [option]`-e, --expiredate` or [option]`-f, --inactive` option.
|
||||
|
||||
[[s1-users-configui]]
|
||||
==== Managing Users in a Graphical Environment
|
||||
== Managing Users in a Graphical Environment
|
||||
indexterm:[users,user configuration]indexterm:[groups,group configuration]indexterm:[user configuration,viewing list of users]indexterm:[group configuration,viewing list of groups]indexterm:[the Users settings tool,user configuration]
|
||||
The [application]*Users* utility allows you to view, modify, add, and delete local users in the graphical user interface.
|
||||
|
||||
[[s2-redhat-config-users-list]]
|
||||
===== Using the Users Settings Tool
|
||||
=== Using the Users Settings Tool
|
||||
|
||||
Press the kbd:[Super] key to enter the Activities Overview, type [command]#Users# and then press kbd:[Enter]. The [application]*Users* settings tool appears. The kbd:[Super] key appears in a variety of guises, depending on the keyboard and other hardware, but often as either the Windows or Command key, and typically to the left of the Spacebar.
|
||||
|
||||
|
|
@ -70,7 +70,7 @@ image::managing_users.png[The Users settings tool]
|
|||
When a new user is created, the account is disabled until a password is set. The Add User menu contains the options to set a password by the administrator immediately, or to allow the user to choose a password at the first login.
|
||||
|
||||
[[s1-users-tools]]
|
||||
==== Using Command Line Tools
|
||||
== Using Command Line Tools
|
||||
indexterm:[users,tools for management of,useradd]indexterm:[users,tools for management of,the Users setting tool]indexterm:[groups,tools for management of,groupadd]
|
||||
Apart from the [application]*Users* settings tool described in xref:Managing_Users_and_Groups.adoc#s1-users-configui[Managing Users in a Graphical Environment], which is designed for basic managing of users, you can use command line tools for managing users and groups that are listed in xref:Managing_Users_and_Groups.adoc#table-users-tools[Command line utilities for managing users and groups].
|
||||
|
||||
|
|
@ -90,7 +90,7 @@ Apart from the [application]*Users* settings tool described in xref:Managing_Use
|
|||
|===
|
||||
|
||||
[[s2-users-tools-users-add]]
|
||||
===== Adding a New User
|
||||
=== Adding a New User
|
||||
indexterm:[useradd command,user account creation using]indexterm:[adding,user]indexterm:[user configuration,command line configuration,useradd]
|
||||
To add a new user to the system, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -240,7 +240,7 @@ drwxr-xr-x. 4 juan juan 4096 Jul 09 08:43 .mozilla
|
|||
At this point, a locked account called `juan` exists on the system. To activate it, the administrator must next assign a password to the account using the [command]#passwd# command and, optionally, set password aging guidelines.
|
||||
|
||||
[[s2-users-tools-groups-add]]
|
||||
===== Adding a New Group
|
||||
=== Adding a New Group
|
||||
indexterm:[group configuration,groupadd]indexterm:[adding,group]
|
||||
To add a new group to the system, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -266,7 +266,7 @@ groupadd pass:quotes[_options_] pass:quotes[_group_name_]
|
|||
|===
|
||||
|
||||
[[s2-users-tools-password-aging]]
|
||||
===== Enabling Password Aging
|
||||
=== Enabling Password Aging
|
||||
indexterm:[password,expire]indexterm:[password,aging]indexterm:[expiration of password, forcing]indexterm:[chage command,forcing password expiration with]indexterm:[user configuration,password,forcing expiration of]
|
||||
For security reasons, it is advisable to require users to change their passwords periodically. This can be done by using the [command]#chage# command.
|
||||
|
||||
|
|
@ -340,7 +340,7 @@ This command sets the value for the date the password was last changed to the ep
|
|||
Upon the initial log in, the user is now prompted for a new password.
|
||||
|
||||
[[s2-users-tools-users-logout]]
|
||||
===== Enabling Automatic Logouts
|
||||
=== Enabling Automatic Logouts
|
||||
|
||||
Especially when the user is logged in as `root`, an unattended login session may pose a significant security risk. To reduce this risk, you can configure the system to automatically log out idle users after a fixed period of time:
|
||||
|
||||
|
|
@ -398,7 +398,7 @@ This way, a password will be required to unlock the session.
|
|||
The changes take effect the next time a user logs in to the system.
|
||||
|
||||
[[s2-users-tools-groups-directories]]
|
||||
===== Creating Group Directories
|
||||
=== Creating Group Directories
|
||||
indexterm:[groups,shared directories]indexterm:[user private groups,and shared directories]
|
||||
System administrators usually like to create a group for each major project and assign people to the group when they need to access that project's files. With this traditional scheme, file management is difficult; when someone creates a file, it is associated with the primary group to which they belong. When a single person works on multiple projects, it becomes difficult to associate the right files with the right group. However, with the UPG scheme, groups are automatically assigned to files created within a directory with the _setgid_ bit set. The setgid bit makes managing group projects that share a common directory very simple because any files a user creates within the directory are owned by the group that owns the directory.
|
||||
|
||||
|
|
@ -449,7 +449,7 @@ drwxrwsr-x. 3 root myproject 4096 Mar 3 18:31 /opt/myproject
|
|||
----
|
||||
|
||||
[[sect-Users_and_Groups-Resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
indexterm:[groups,additional resources]indexterm:[users,additional resources]
|
||||
For more information on how to manage users and groups on Fedora, see the resources listed below.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,12 +3,12 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-Opening_GUI_Applications]]
|
||||
=== Opening Graphical Applications
|
||||
= Opening Graphical Applications
|
||||
indexterm:[GUI]
|
||||
Fedora provides graphical applications in addition to command line utilities for configuring many features. This chapter describes methods for opening `Graphical User Interface`, or _GUI_, applications in various environments.
|
||||
|
||||
[[gui-from_cli]]
|
||||
==== Opening graphical applications from the command line
|
||||
== Opening graphical applications from the command line
|
||||
|
||||
Graphical applications can be launched from a terminal window or console session by simply typing the name of the application.
|
||||
|
||||
|
|
@ -105,7 +105,7 @@ root 23874 0.0 0.0 109184 900 pts/21 S+ 15:35 0:00 grep --color=au
|
|||
. Switch back to the TTY the graphical session is running on. Since the example above shows [application]*X* running on `vt1`, pressing kbd:[Ctrl + Alt + F1] will return to the desktop environment.
|
||||
|
||||
[[gui-alt_f2]]
|
||||
==== Launching Applications with kbd:[Alt + F2]
|
||||
== Launching Applications with kbd:[Alt + F2]
|
||||
|
||||
Most desktop environments follow the convention of using the key combination kbd:[Alt + F2] for opening new applications. Pressing kbd:[Alt + F2] brings up a prompt for a command to be entered into.
|
||||
|
||||
|
|
@ -137,12 +137,12 @@ image::alt-f2_MATE.png[MATE command entry dialog box.]
|
|||
image::alt-f2_XFCE.png[XFCE command entry dialog box.]
|
||||
|
||||
[[gui-from_menu]]
|
||||
==== Launching applications from the Desktop Menu
|
||||
== Launching applications from the Desktop Menu
|
||||
|
||||
Applications can also be opened from the menu system provided by the desktop environment in use. While the presentation may vary between desktop environments, the menu entries and their categories are provided by the individual application and standardized by the link:++http://standards.freedesktop.org/menu-spec/menu-spec-latest.html++[freedesktop.org Desktop Menu Specification]. Some desktop environments also provide search functionality in their menu system to allow quick and easy access to applications.
|
||||
|
||||
[[gui-from_menu-gnome]]
|
||||
===== Using GNOME menus
|
||||
=== Using GNOME menus
|
||||
|
||||
The GNOME menu, called the `overview`, can be accessed by either clicking the `Activities` button in the top left of the primary display, by moving the mouse past the top left `hot corner`, or by pressing the kbd:[Super] ( kbd:[Windows] ) key. The `overview` presents documents in addition to applications.
|
||||
|
||||
|
|
@ -163,7 +163,7 @@ image::menu_GNOME.png[The GNOME menu has a bar on the left for frequently used a
|
|||
To learn more about using [application]*GNOME shell*, visit link:++https://wiki.gnome.org/GnomeShell/CheatSheet++[]
|
||||
|
||||
[[gui-from_menu-kde]]
|
||||
===== Using KDE menus
|
||||
=== Using KDE menus
|
||||
|
||||
The KDE menu is opened by clicking the {MAJOROS} button at the bottom left corner of the screen. The menu initially displays favorite applications, which can be added to by right clicking any menu entry. Hovering over the icons in the lower portion of the menu will display applications, file systems, recently used applications, or options for logging out of the system.
|
||||
|
||||
|
|
@ -179,7 +179,7 @@ Search functionality is also available in the KDE menu system. To search for app
|
|||
|
||||
image::searchmenu_KDE.png[The KDE menu will search for matching applications if you type into the search box. For example, typing browser will display installed browsers and other matching entries.]
|
||||
|
||||
===== Using menus in LXDE, MATE, and XFCE
|
||||
=== Using menus in LXDE, MATE, and XFCE
|
||||
|
||||
Menus in LXDE, MATE, and XFCE have a varied appearance but a very similar structure. They categorize applications, and the contents of a category are displayed by hovering the cursor over the entry. Applications are launched by clicking on an entry.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,14 +3,14 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-System_Locale_and_Keyboard_Configuration]]
|
||||
=== System Locale and Keyboard Configuration
|
||||
= System Locale and Keyboard Configuration
|
||||
indexterm:[keyboard configuration]
|
||||
The *system locale* specifies the language settings of system services and user interfaces. The *keyboard layout* settings control the layout used on the text console and graphical user interfaces.
|
||||
|
||||
These settings can be made by modifying the `/etc/locale.conf` configuration file or by using the [application]*localectl* utility. Also, you can use the graphical user interface to perform the task; for a description of this method, see link:++https://docs.fedoraproject.org/install-guide++[{MAJOROS} Installation Guide].
|
||||
|
||||
[[s1-Setting_the_System_Locale]]
|
||||
==== Setting the System Locale
|
||||
== Setting the System Locale
|
||||
|
||||
System-wide locale settings are stored in the `/etc/locale.conf` file, which is read at early boot by the `systemd` daemon. The locale settings configured in `/etc/locale.conf` are inherited by every service or user, unless individual programs or individual users override them.
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ Here, the LC_MESSAGES option determines the locale used for diagnostic messages
|
|||
|===
|
||||
|
||||
[[s2-Displaying_the_Current_Status]]
|
||||
===== Displaying the Current Status
|
||||
=== Displaying the Current Status
|
||||
|
||||
The [command]#localectl# command can be used to query and change the system locale and keyboard layout settings. To show the current settings, use the [option]`status` option:
|
||||
|
||||
|
|
@ -67,7 +67,7 @@ The output of the previous command lists the currently set locale, keyboard layo
|
|||
====
|
||||
|
||||
[[s2-Listing_Available_Locales]]
|
||||
===== Listing Available Locales
|
||||
=== Listing Available Locales
|
||||
|
||||
To list all locales available for your system, type:
|
||||
|
||||
|
|
@ -101,7 +101,7 @@ pass:quotes[*output truncated*]
|
|||
====
|
||||
|
||||
[[s2-Setting_the_Locale]]
|
||||
===== Setting the Locale
|
||||
=== Setting the Locale
|
||||
|
||||
To set the default system locale, use the following command as `root`:
|
||||
|
||||
|
|
@ -125,12 +125,12 @@ For example, if you want to set British English as your default locale, first fi
|
|||
====
|
||||
|
||||
[[s1-Changing_the_Keyboard_Layout]]
|
||||
==== Changing the Keyboard Layout
|
||||
== Changing the Keyboard Layout
|
||||
indexterm:[localectl,keyboard configuration]indexterm:[keyboard configuration,layout]
|
||||
The keyboard layout settings enable the user to control the layout used on the text console and graphical user interfaces.
|
||||
|
||||
[[s2-Displaying_the_Current_Settings]]
|
||||
===== Displaying the Current Settings
|
||||
=== Displaying the Current Settings
|
||||
|
||||
As mentioned before, you can check your current keyboard layout configuration with the following command:
|
||||
|
||||
|
|
@ -157,7 +157,7 @@ In the following output, you can see the keyboard layout configured for the virt
|
|||
====
|
||||
|
||||
[[s2-Listing_Available_Keymaps]]
|
||||
===== Listing Available Keymaps
|
||||
=== Listing Available Keymaps
|
||||
|
||||
To list all available keyboard layouts that can be configured on your system, type:
|
||||
|
||||
|
|
@ -190,7 +190,7 @@ sunt5-us-cz
|
|||
====
|
||||
|
||||
[[s2-Setting_the_Keymap]]
|
||||
===== Setting the Keymap
|
||||
=== Setting the Keymap
|
||||
|
||||
To set the default keyboard layout for your system, use the following command as `root`:
|
||||
|
||||
|
|
@ -250,7 +250,7 @@ Replace _model_ with the keyboard model name,
|
|||
_variant_ and _options_ with keyboard variant and option components, which can be used to enhance the keyboard behavior. These options are not set by default. For more information on X11 Model, X11 Variant, and X11 Options see the `kbd(4)` man page.
|
||||
|
||||
[[sect-Keyboard_Configuration-Resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
|
||||
For more information on how to configure the keyboard layout on Fedora, see the resources listed below:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
== Basic System Configuration
|
||||
= Basic System Configuration
|
||||
|
||||
This part covers basic system administration tasks such as keyboard configuration, date and time configuration, managing users and groups, and gaining privileges.
|
||||
|
|
|
|||
|
|
@ -1,22 +1,11 @@
|
|||
|
||||
:BOOKID: system-administrator's-guide
|
||||
|
||||
:BZURL: link:++https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20Documentation&component=system-administrator's-guide++[http://bugzilla.redhat.com/]
|
||||
|
||||
:HOLDER: Red Hat, Inc. and others
|
||||
|
||||
:MAJOROS: Fedora
|
||||
|
||||
:MAJOROSVER: Fedora Rawhide
|
||||
|
||||
:OSORG: The Fedora Project
|
||||
|
||||
:PKGOS: fcRawhide
|
||||
|
||||
:PRODUCT: Fedora Documentation
|
||||
|
||||
:PRODVER: Rawhide
|
||||
|
||||
:YEAR: 2017
|
||||
|
||||
:nbsp: pass:q[ ]
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-OpenSSH]]
|
||||
=== OpenSSH
|
||||
= OpenSSH
|
||||
indexterm:[OpenSSH]
|
||||
`SSH` (Secure Shell) is a protocol which facilitates secure communications between two systems using a client-server architecture and allows users to log into server host systems remotely. Unlike other remote communication protocols, such as `FTP`, `Telnet`, or [command]#rlogin#, SSH encrypts the login session, rendering the connection difficult for intruders to collect unencrypted passwords.
|
||||
|
||||
|
|
@ -12,10 +12,10 @@ The [application]*ssh* program is designed to replace older, less secure termina
|
|||
{MAJOROS} includes the general OpenSSH package, [package]*openssh*, as well as the OpenSSH server, [package]*openssh-server*, and client, [package]*openssh-clients*, packages. Note, the OpenSSH packages require the OpenSSL package [package]*openssl-libs*, which installs several important cryptographic libraries, enabling OpenSSH to provide encrypted communications.
|
||||
|
||||
[[s1-ssh-protocol]]
|
||||
==== The SSH Protocol
|
||||
== The SSH Protocol
|
||||
|
||||
[[s2-ssh-why]]
|
||||
===== Why Use SSH?
|
||||
=== Why Use SSH?
|
||||
indexterm:[SSH protocol,security risks]
|
||||
Potential intruders have a variety of tools at their disposal enabling them to disrupt, intercept, and re-route network traffic in an effort to gain access to a system. In general terms, these threats can be categorized as follows:
|
||||
|
||||
|
|
@ -30,7 +30,7 @@ This attack can be performed using a technique known as _DNS poisoning_, or via
|
|||
Both techniques intercept potentially sensitive information and, if the interception is made for hostile reasons, the results can be disastrous. If SSH is used for remote shell login and file copying, these security threats can be greatly diminished. This is because the SSH client and server use digital signatures to verify their identity. Additionally, all communication between the client and server systems is encrypted. Attempts to spoof the identity of either side of a communication does not work, since each packet is encrypted using a key known only by the local and remote systems.
|
||||
|
||||
[[s2-ssh-features]]
|
||||
===== Main Features
|
||||
=== Main Features
|
||||
indexterm:[SSH protocol,features]indexterm:[OpenSSH,SSH]
|
||||
The SSH protocol provides the following safeguards:
|
||||
|
||||
|
|
@ -51,7 +51,7 @@ It can be used to create a secure channel:: The OpenSSH server and client can b
|
|||
It supports Kerberos authentication:: OpenSSH servers and clients can be configured to authenticate using the *GSSAPI* (Generic Security Services Application Program Interface) implementation of the Kerberos network authentication protocol.
|
||||
|
||||
[[s2-ssh-versions]]
|
||||
===== Protocol Versions
|
||||
=== Protocol Versions
|
||||
indexterm:[SSH protocol,version 1]indexterm:[SSH protocol,version 2]
|
||||
Two varieties of SSH currently exist: version 1 and version 2. The OpenSSH suite under {MAJOROS} uses SSH version 2, which has an enhanced key exchange algorithm not vulnerable to the known exploit in version 1. However, for compatibility reasons, the OpenSSH suite does support version 1 connections as well, although version 1 is disabled by default and needs to be enabled in the configuration files.
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ To ensure maximum security for your connection, it is recommended that only SSH
|
|||
====
|
||||
|
||||
[[s2-ssh-conn]]
|
||||
===== Event Sequence of an SSH Connection
|
||||
=== Event Sequence of an SSH Connection
|
||||
indexterm:[SSH protocol,connection sequence]
|
||||
The following series of events help protect the integrity of SSH communication between two hosts.
|
||||
|
||||
|
|
@ -77,7 +77,7 @@ The following series of events help protect the integrity of SSH communication b
|
|||
. The client interacts with the remote host over the encrypted connection.
|
||||
|
||||
[[s2-ssh-protocol-conn-transport]]
|
||||
====== Transport Layer
|
||||
==== Transport Layer
|
||||
indexterm:[SSH protocol,layers,transport layer]
|
||||
The primary role of the transport layer is to facilitate safe and secure communication between the two hosts at the time of authentication and during subsequent communication. The transport layer accomplishes this by handling the encryption and decryption of data, and by providing integrity protection of data packets as they are sent and received. The transport layer also provides compression, speeding the transfer of information.
|
||||
|
||||
|
|
@ -108,14 +108,14 @@ SSH is designed to work with almost any kind of public key algorithm or encoding
|
|||
After a certain amount of data has been transmitted using a given key and algorithm (the exact amount depends on the SSH implementation), another key exchange occurs, generating another set of hash values and a new shared secret value. Even if an attacker is able to determine the hash and shared secret value, this information is only useful for a limited period of time.
|
||||
|
||||
[[s2-ssh-protocol-authentication]]
|
||||
====== Authentication
|
||||
==== Authentication
|
||||
indexterm:[SSH protocol,authentication]
|
||||
Once the transport layer has constructed a secure tunnel to pass information between the two systems, the server tells the client the different authentication methods supported, such as using a private key-encoded signature or typing a password. The client then tries to authenticate itself to the server using one of these supported methods.
|
||||
|
||||
SSH servers and clients can be configured to allow different types of authentication, which gives each side the optimal amount of control. The server can decide which encryption methods it supports based on its security model, and the client can choose the order of authentication methods to attempt from the available options.
|
||||
|
||||
[[s2-ssh-protocol-connection]]
|
||||
====== Channels
|
||||
==== Channels
|
||||
indexterm:[SSH protocol,layers,channels]
|
||||
After a successful authentication over the SSH transport layer, multiple channels are opened via a technique called _multiplexing_pass:attributes[{blank}]footnote:[A multiplexed connection consists of several signals being sent over a shared, common medium. With SSH, different channels are sent over a common secure connection.]. Each of these channels handles communication for different terminal sessions and for forwarded X11 sessions.
|
||||
|
||||
|
|
@ -126,7 +126,7 @@ Channels also support _flow-control_, which allows them to send and receive data
|
|||
The client and server negotiate the characteristics of each channel automatically, depending on the type of service the client requests and the way the user is connected to the network. This allows great flexibility in handling different types of remote connections without having to change the basic infrastructure of the protocol.
|
||||
|
||||
[[s1-ssh-configuration]]
|
||||
==== Configuring OpenSSH
|
||||
== Configuring OpenSSH
|
||||
|
||||
In order to perform tasks described in this section, you must have superuser privileges. To obtain them, log in as `root` by typing:
|
||||
|
||||
|
|
@ -136,7 +136,7 @@ In order to perform tasks described in this section, you must have superuser pri
|
|||
----
|
||||
|
||||
[[s2-ssh-configuration-configs]]
|
||||
===== Configuration Files
|
||||
=== Configuration Files
|
||||
indexterm:[SSH protocol,configuration files]
|
||||
There are two different sets of configuration files: those for client programs (that is, [command]#ssh#, [command]#scp#, and [command]#sftp#), and those for the server (the [command]#sshd# daemon).
|
||||
indexterm:[SSH protocol,configuration files,system-wide configuration files]indexterm:[SSH protocol,configuration files,user-specific configuration files]
|
||||
|
|
@ -180,7 +180,7 @@ System-wide SSH configuration information is stored in the `/etc/ssh/` directory
|
|||
For information concerning various directives that can be used in the SSH configuration files, see the `ssh_config`(5) and `sshd_config`(5) manual pages.
|
||||
|
||||
[[s2-ssh-configuration-sshd]]
|
||||
===== Starting an OpenSSH Server
|
||||
=== Starting an OpenSSH Server
|
||||
indexterm:[OpenSSH,server]
|
||||
|
||||
.Make sure you have relevant packages installed
|
||||
|
|
@ -230,7 +230,7 @@ It is also possible that the RSA host key has just been changed.
|
|||
To prevent this, you can backup the relevant files from the `/etc/ssh/` directory (see xref:OpenSSH.adoc#table-ssh-configuration-configs-system[System-wide configuration files] for a complete list), and restore them whenever you reinstall the system.
|
||||
|
||||
[[s2-ssh-configuration-requiring]]
|
||||
===== Requiring SSH for Remote Connections
|
||||
=== Requiring SSH for Remote Connections
|
||||
indexterm:[SSH protocol,insecure protocols]indexterm:[SSH protocol,requiring for remote login]
|
||||
For SSH to be truly effective, using insecure connection protocols should be prohibited. Otherwise, a user's password may be protected using SSH for one session, only to be captured later while logging in using Telnet. Some services to disable include [command]#telnet#, [command]#rsh#, [command]#rlogin#, and [command]#vsftpd#.
|
||||
|
||||
|
|
@ -257,7 +257,7 @@ To disable running these services at startup, type:
|
|||
See xref:Services_and_Daemons.adoc#ch-Services_and_Daemons[Services and Daemons] for more information on how to configure services in {MAJOROS}.
|
||||
|
||||
[[s2-ssh-configuration-keypairs]]
|
||||
===== Using Key-based Authentication
|
||||
=== Using Key-based Authentication
|
||||
indexterm:[OpenSSH,using key-based authentication]
|
||||
To improve the system security even further, generate SSH key pairs and then enforce key-based authentication by disabling password authentication. To do so, open the `/etc/ssh/sshd_config` configuration file in a text editor such as [application]*vi* or [application]*nano*, and change the [option]`PasswordAuthentication` option as follows:
|
||||
|
||||
|
|
@ -289,7 +289,7 @@ If you reinstall your system and want to keep previously generated key pairs, ba
|
|||
====
|
||||
|
||||
[[s3-ssh-configuration-keypairs-generating]]
|
||||
====== Generating Key Pairs
|
||||
==== Generating Key Pairs
|
||||
indexterm:[RSA keys,generating]indexterm:[OpenSSH,RSA keys,generating]
|
||||
To generate an RSA key pair for version 2 of the SSH protocol, follow these steps:
|
||||
indexterm:[OpenSSH,ssh-keygen,RSA]
|
||||
|
|
@ -424,7 +424,7 @@ The private key is for your personal use only, and it is important that you neve
|
|||
====
|
||||
|
||||
[[s3-ssh-configuration-keypairs-agent]]
|
||||
====== Configuring ssh-agent
|
||||
==== Configuring ssh-agent
|
||||
indexterm:[OpenSSH,ssh-agent]indexterm:[ssh-agent]
|
||||
To store your passphrase so that you do not have to enter it each time you initiate a connection with a remote machine, you can use the [command]#ssh-agent# authentication agent.
|
||||
|
||||
|
|
@ -439,10 +439,10 @@ Enter passphrase for /home/USER/.ssh/id_rsa:
|
|||
Note that when you log out, your passphrase will be forgotten. You must execute the command each time you log in to a virtual console or a terminal window.
|
||||
|
||||
[[sec-Using_OpenSSH_Certificate_Authentication]]
|
||||
==== Using OpenSSH Certificate Authentication
|
||||
== Using OpenSSH Certificate Authentication
|
||||
|
||||
[[sec-Introduction_to_SSH_Certificates]]
|
||||
===== Introduction to SSH Certificates
|
||||
=== Introduction to SSH Certificates
|
||||
|
||||
Using public key cryptography for authentication requires copying the public key from every client to every server that the client intends to log into. This system does not scale well and can be an administrative burden. Using a public key from a _certificate authority_ (*CA*) to authenticate client certificates removes the need to copy keys between multiple systems. While the X.509 Public Key Infrastructure Certificate system provides a solution to this issue, there is a submission and validation process, with associated fees, to go through in order to get a certificate signed. As an alternative, OpenSSH supports the creation of simple certificates and associated CA infrastructure.
|
||||
|
||||
|
|
@ -451,7 +451,7 @@ OpenSSH certificates contain a public key, identity information, and validity co
|
|||
The [command]#ssh-keygen# utility supports two types of certificates: user and host. User certificates authenticate users to servers, whereas host certificates authenticate server hosts to users. For certificates to be used for user or host authentication, `sshd` must be configured to trust the CA public key.
|
||||
|
||||
[[sec-Support_for_OpenSSH_Certificates]]
|
||||
===== Support for SSH Certificates
|
||||
=== Support for SSH Certificates
|
||||
|
||||
Support for certificate authentication of users and hosts using the new OpenSSH certificate format was introduced in Fedora 13, in the [package]*openssh-5.4p1-1.fc13* package. If required, to ensure the latest OpenSSH package is installed, enter the following command as `root`:
|
||||
|
||||
|
|
@ -462,7 +462,7 @@ Package openssh-7.1p1-1.fc23.x86_64 is already installed, skipping.
|
|||
----
|
||||
|
||||
[[sec-Creating_SSH_CA_Certificate_Signing-Keys]]
|
||||
===== Creating SSH CA Certificate Signing Keys
|
||||
=== Creating SSH CA Certificate Signing Keys
|
||||
|
||||
Two types of certificates are required, host certificates and user certificates. It is considered better to have two separate keys for signing the two certificates, for example `ca_user_key` and `ca_host_key`, however it is possible to use just one CA key to sign both certificates. It is also easier to follow the procedures if separate keys are used, so the examples that follow will use separate keys.
|
||||
|
||||
|
|
@ -589,7 +589,7 @@ Signed host key /root/.ssh/ssh_host_rsa-cert.pub: id "host_name" serial 0 for ho
|
|||
----
|
||||
|
||||
[[sec-Distributing_and_Trusting_SSH_CA_Public_Keys]]
|
||||
===== Distributing and Trusting SSH CA Public Keys
|
||||
=== Distributing and Trusting SSH CA Public Keys
|
||||
|
||||
Hosts that are to allow certificate authenticated log in from users must be configured to trust the CA's public key that was used to sign the user certificates, in order to authenticate user's certificates. In this example that is the `ca_user_key.pub`.
|
||||
|
||||
|
|
@ -652,7 +652,7 @@ ssh-rsa pass:quotes[_AAAAB5Wm._]== root@ca-server.example.com
|
|||
Where `ssh-rsa _AAAAB5Wm._pass:attributes[{blank}]` is the contents of `ca_host_key.pub`. The above configures the system to trust the CA servers host public key. This enables global authentication of the certificates presented by hosts to remote users.
|
||||
|
||||
[[sec-Signing_SSH_Certificates]]
|
||||
===== Creating SSH Certificates
|
||||
=== Creating SSH Certificates
|
||||
|
||||
A certifcate is a signed public key. The user's and host's public keys must be copied to the CA server for signing by the CA server's private key.
|
||||
|
||||
|
|
@ -681,7 +681,7 @@ drwx------. 3 admin admin 4096 May 22 16:17 ..
|
|||
----
|
||||
|
||||
[[sec-Creating_SSH_Certificates_to_Authenticate_Hosts]]
|
||||
====== Creating SSH Certificates to Authenticate Hosts
|
||||
==== Creating SSH Certificates to Authenticate Hosts
|
||||
|
||||
The command to sign a host certificate has the following format:
|
||||
|
||||
|
|
@ -761,7 +761,7 @@ HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
|
|||
To test the host certificate, on a client system, ensure the client has set up the global `/etc/ssh/known_hosts` file, as described in xref:OpenSSH.adoc#proc-Trusting_the_Host_Signing_Key[Trusting the Host Signing Key], and that the server's public key is not in the `~/.ssh/known_hosts` file. Then attempt to log into the server over SSH as a remote user. You should not see a warning about the authenticity of the host. If required, add the [option]`-v` option to the SSH command to see logging information.
|
||||
|
||||
[[sec-Creating_SSH_Certificates_for_Authenticating_Users]]
|
||||
====== Creating SSH Certificates for Authenticating Users
|
||||
==== Creating SSH Certificates for Authenticating Users
|
||||
|
||||
To sign a user's certificate, use a command in the following format:
|
||||
|
||||
|
|
@ -904,7 +904,7 @@ This will enable the user of this system to be authenticated by a user certifica
|
|||
. To test the user certificate, attempt to log into a server over SSH from the user's account. You should do this as the user listed as a principle in the certificate, if any are specified. You should not be prompted for a password. If required, add the [option]`-v` option to the SSH command to see logging information.
|
||||
|
||||
[[sec-SSH_Certificate_PKCS_11_Token]]
|
||||
===== Signing an SSH Certificate Using a PKCS#11 Token
|
||||
=== Signing an SSH Certificate Using a PKCS#11 Token
|
||||
|
||||
It is possible to sign a host key using a CA key stored in a PKCS#11 token by providing the token library using the [option]`-D` and identifying the CA key by providing its public half as an argument to the [option]`-s` option:
|
||||
|
||||
|
|
@ -946,7 +946,7 @@ A certificate that is presented at a time outside this range will not be conside
|
|||
By default, certificates are valid indefinitely starting from UNIX Epoch.
|
||||
|
||||
[[sec-Viewing_an_SSH_CA_Certificate]]
|
||||
===== Viewing an SSH CA Certificate
|
||||
=== Viewing an SSH CA Certificate
|
||||
|
||||
To view a certificate, use the [option]`-L` to list the contents. For example, for a user's certificate:
|
||||
|
||||
|
|
@ -988,7 +988,7 @@ To vew a host certificate:
|
|||
----
|
||||
|
||||
[[sec-Revoking_an_SSH_CA_Certificate]]
|
||||
===== Revoking an SSH CA Certificate
|
||||
=== Revoking an SSH CA Certificate
|
||||
|
||||
If a certificate is stolen, it should be revoked. Although OpenSSH does not provide a mechanism to distribute the revocation list it is still easier to create the revocation list and distribute it by other means then to change the CA keys and all host and user certificates previously created and distributed.
|
||||
|
||||
|
|
@ -1024,7 +1024,7 @@ ssh-keygen -Qf /etc/ssh/revoked_keys ~/.ssh/id_rsa.pub
|
|||
A user can revoke a CA certificate by changing the [command]#cert-authority# directive to [command]#revoke# in the `known_hosts` file.
|
||||
|
||||
[[s1-ssh-clients]]
|
||||
==== OpenSSH Clients
|
||||
== OpenSSH Clients
|
||||
indexterm:[OpenSSH,client]
|
||||
|
||||
.Make sure you have relevant packages installed
|
||||
|
|
@ -1036,7 +1036,7 @@ To connect to an OpenSSH server from a client machine, you must have the [packag
|
|||
====
|
||||
|
||||
[[s2-ssh-clients-ssh]]
|
||||
===== Using the ssh Utility
|
||||
=== Using the ssh Utility
|
||||
indexterm:[ssh,OpenSSH]indexterm:[OpenSSH,client,ssh]
|
||||
The [command]#ssh# utility allows you to log in to a remote machine and execute commands there. It is a secure replacement for the [command]#rlogin#, [command]#rsh#, and [command]#telnet# programs.
|
||||
|
||||
|
|
@ -1132,7 +1132,7 @@ Fedora release 20 (Heisenbug)
|
|||
After you enter the correct password, the user name will be displayed, and you will return to your local shell prompt.
|
||||
|
||||
[[s2-ssh-clients-scp]]
|
||||
===== Using the [command]#scp# Utility
|
||||
=== Using the [command]#scp# Utility
|
||||
indexterm:[scp,OpenSSH]indexterm:[OpenSSH,client,scp]indexterm:[rcp]
|
||||
[command]#scp# can be used to transfer files between machines over a secure, encrypted connection. In its design, it is very similar to [command]#rcp#.
|
||||
|
||||
|
|
@ -1180,7 +1180,7 @@ USER@penguin.example.com's password:
|
|||
----
|
||||
|
||||
[[s2-ssh-clients-sftp]]
|
||||
===== Using the [command]#sftp# Utility
|
||||
=== Using the [command]#sftp# Utility
|
||||
indexterm:[sftp,OpenSSH]indexterm:[OpenSSH,client,sftp]
|
||||
The [command]#sftp# utility can be used to open a secure, interactive FTP session. In its design, it is similar to [command]#ftp# except that it uses a secure, encrypted connection.
|
||||
|
||||
|
|
@ -1220,12 +1220,12 @@ After you enter the correct password, you will be presented with a prompt. The [
|
|||
For a complete list of available commands, see the `sftp`(1) manual page.
|
||||
|
||||
[[s1-ssh-beyondshell]]
|
||||
==== More Than a Secure Shell
|
||||
== More Than a Secure Shell
|
||||
|
||||
A secure command line interface is just the beginning of the many ways SSH can be used. Given the proper amount of bandwidth, X11 sessions can be directed over an SSH channel. Or, by using TCP/IP forwarding, previously insecure port connections between systems can be mapped to specific SSH channels.
|
||||
|
||||
[[s2-ssh-beyondshell-x11]]
|
||||
===== X11 Forwarding
|
||||
=== X11 Forwarding
|
||||
indexterm:[SSH protocol,X11 forwarding]
|
||||
To open an X11 session over an SSH connection, use a command in the following form:
|
||||
|
||||
|
|
@ -1260,7 +1260,7 @@ X11 forwarding can be very useful. For example, X11 forwarding can be used to cr
|
|||
The [application]*Print Settings* tool will appear, allowing the remote user to safely configure printing on the remote system.
|
||||
|
||||
[[s2-ssh-beyondshell-tcpip]]
|
||||
===== Port Forwarding
|
||||
=== Port Forwarding
|
||||
indexterm:[SSH protocol,port forwarding]
|
||||
SSH can secure otherwise insecure `TCP/IP` protocols via port forwarding. When using this technique, the SSH server becomes an encrypted conduit to the SSH client.
|
||||
|
||||
|
|
@ -1312,7 +1312,7 @@ System administrators concerned about port forwarding can disable this functiona
|
|||
====
|
||||
|
||||
[[s1-openssh-additional-resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
indexterm:[OpenSSH,additional resources]indexterm:[OpenSSL,additional resources]
|
||||
For more information on how to configure or connect to an OpenSSH server on Fedora, see the resources listed below.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-Services_and_Daemons]]
|
||||
=== Services and Daemons
|
||||
= Services and Daemons
|
||||
indexterm:[services configuration]
|
||||
Maintaining security on your system is extremely important, and one approach for this task is to manage access to system services carefully. Your system may need to provide open access to particular services (for example, `httpd` if you are running a web server). However, if you do not need to provide a service, you should turn it off to minimize your exposure to possible bug exploits.
|
||||
|
||||
|
|
@ -18,7 +18,7 @@ When you allow access for new services, always remember that both the firewall a
|
|||
====
|
||||
|
||||
[[s1-services-configuring]]
|
||||
==== Configuring Services
|
||||
== Configuring Services
|
||||
indexterm:[systemctl,services configuration]indexterm:[services configuration,systemctl]
|
||||
To allow you to configure which services are started at boot time, {MAJOROS} is shipped with the [application]*systemctl* command line tool.
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ To ensure optimal performance on POWER architecture, it is recommended that the
|
|||
====
|
||||
|
||||
[[s3-services-configuration-enabling]]
|
||||
===== Enabling the Service
|
||||
=== Enabling the Service
|
||||
|
||||
To configure a service to be automatically started at boot time, use the [command]#systemctl# command in the following form:
|
||||
|
||||
|
|
@ -67,7 +67,7 @@ Imagine you want to run the Apache HTTP Server on your system. Provided that you
|
|||
====
|
||||
|
||||
[[s3-services-configuration-disabling]]
|
||||
===== Disabling the Service
|
||||
=== Disabling the Service
|
||||
|
||||
To disable starting a service at boot time, use the [command]#systemctl# command in the following form:
|
||||
|
||||
|
|
@ -90,7 +90,7 @@ In order to secure the system, users are advised to disable insecure connection
|
|||
====
|
||||
|
||||
[[s1-services-running]]
|
||||
==== Running Services
|
||||
== Running Services
|
||||
indexterm:[systemctl,services configuration]indexterm:[services configuration,ssystemctl]
|
||||
The [application]*systemctl* utility also allows you to determine the status of a particular service, as well as to start, stop, or restart a service.
|
||||
|
||||
|
|
@ -103,7 +103,7 @@ Although it is still possible to use the [application]*service* utility to manag
|
|||
====
|
||||
|
||||
[[s3-services-running-checking]]
|
||||
===== Checking the Service Status
|
||||
=== Checking the Service Status
|
||||
|
||||
To determine the status of a particular service, use the [command]#systemctl# command in the following form:
|
||||
|
||||
|
|
@ -196,7 +196,7 @@ In the example above, the `abrtd` service is loaded, active, and running, and it
|
|||
====
|
||||
|
||||
[[s3-services-running-running]]
|
||||
===== Running the Service
|
||||
=== Running the Service
|
||||
|
||||
To run a service, use the [command]#systemctl# command in the following form:
|
||||
|
||||
|
|
@ -219,7 +219,7 @@ xref:Services_and_Daemons.adoc#exam-services-configuration-enabling[Enabling the
|
|||
====
|
||||
|
||||
[[s3-services-running-stopping]]
|
||||
===== Stopping the Service
|
||||
=== Stopping the Service
|
||||
|
||||
To stop a service, use the [command]#systemctl# command in the following form:
|
||||
|
||||
|
|
@ -242,7 +242,7 @@ xref:Services_and_Daemons.adoc#exam-services-configuration-disabling[Disabling t
|
|||
====
|
||||
|
||||
[[s3-services-running-restarting]]
|
||||
===== Restarting the Service
|
||||
=== Restarting the Service
|
||||
|
||||
To restart a service, use the [command]#systemctl# command in the following form:
|
||||
|
||||
|
|
@ -263,14 +263,14 @@ For any changes in the `/etc/ssh/sshd_config` configuration file to take effect,
|
|||
====
|
||||
|
||||
[[s1-services-additional-resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
|
||||
[[s2-services-additional-resources-installed]]
|
||||
===== Installed Documentation
|
||||
=== Installed Documentation
|
||||
|
||||
* `systemctl`(1) — The manual page for the [application]*systemctl* utility.
|
||||
|
||||
[[s2-services-additional-resources-books]]
|
||||
===== Related Books
|
||||
=== Related Books
|
||||
|
||||
[citetitle]_{MAJOROSVER} Security Guide_:: A guide to securing {MAJOROS}. It contains valuable information on how to set up the firewall, as well as the configuration of [application]*SELinux*.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-TigerVNC]]
|
||||
=== TigerVNC
|
||||
= TigerVNC
|
||||
|
||||
`TigerVNC` (Tiger Virtual Network Computing) is a system
|
||||
for graphical desktop sharing which allows you to remotely control other computers.
|
||||
|
|
@ -22,7 +22,7 @@ by `/etc/systemd/system/vncserver@.service`.
|
|||
====
|
||||
|
||||
[[s1-vnc-server]]
|
||||
==== VNC Server
|
||||
== VNC Server
|
||||
|
||||
`vncserver` is a utility which starts a VNC (Virtual
|
||||
Network Computing) desktop. It runs [application]*Xvnc* with appropriate options and starts a window
|
||||
|
|
@ -31,7 +31,7 @@ separate sessions in parallel on a machine which can then be accessed by any num
|
|||
from anywhere.
|
||||
|
||||
[[s2-vnc-installation]]
|
||||
===== Installing VNC Server
|
||||
=== Installing VNC Server
|
||||
|
||||
To install the [application]*TigerVNC* server, issue the following command as `root`:
|
||||
|
||||
|
|
@ -41,7 +41,7 @@ To install the [application]*TigerVNC* server, issue the following command as `r
|
|||
----
|
||||
|
||||
[[s3-configuring-vnc-server]]
|
||||
===== Configuring VNC Server
|
||||
=== Configuring VNC Server
|
||||
|
||||
[[configuring-vncserver]]
|
||||
.Configuring the first VNC connection
|
||||
|
|
@ -105,7 +105,7 @@ file can find the plain-text password.
|
|||
Proceed to xref:TigerVNC.adoc#s4-starting-vncserver[Starting VNC Server].
|
||||
|
||||
[[configuring-vncserver-2users]]
|
||||
====== Configuring VNC Server for Two Users
|
||||
==== Configuring VNC Server for Two Users
|
||||
|
||||
If you want to configure more than one user on the same machine,
|
||||
create different template-type service files, one for each user.
|
||||
|
|
@ -131,7 +131,7 @@ Verify:
|
|||
----
|
||||
|
||||
[[s4-starting-vncserver]]
|
||||
===== Starting VNC Server
|
||||
=== Starting VNC Server
|
||||
|
||||
To start or enable the service, specify the display number directly in the command.
|
||||
The file configured above in xref:TigerVNC.adoc#configuring-vncserver[Configuring the first VNC connection] works as a template, in which `%i` is substituted with
|
||||
|
|
@ -157,7 +157,7 @@ You can also enable the service to start automatically at system start. Then, wh
|
|||
At this point, other users are able to use a VNC viewer program to connect to the VNC server using the display number and password defined. Provided a graphical desktop is installed, an instance of that desktop will be displayed. It will not be the same instance as that currently displayed on the target machine.
|
||||
|
||||
[[starting-vncserver-2displays]]
|
||||
====== Configuring VNC Server for Two Users and Two Different Displays
|
||||
==== Configuring VNC Server for Two Users and Two Different Displays
|
||||
|
||||
For the two configured VNC servers, vncserver-USER_1@.service and vncserver-USER_2@.service,
|
||||
you can enable different display numbers. For example, the following commands will cause a VNC server for USER_1 to
|
||||
|
|
@ -172,7 +172,7 @@ start on display 3, and a VNC server for USER_2 to start on display 5:
|
|||
----
|
||||
|
||||
[[terminating-vnc-session]]
|
||||
===== Terminating a VNC Session
|
||||
=== Terminating a VNC Session
|
||||
|
||||
Similarly to enabling the `vncserver` service, you can disable
|
||||
the automatic start of the service at system start:
|
||||
|
|
@ -195,7 +195,7 @@ command as `root`:
|
|||
----
|
||||
|
||||
[[s5-vnc-viewer]]
|
||||
==== VNC Viewer
|
||||
== VNC Viewer
|
||||
|
||||
`vncviewer` is the program which shows the shared graphical
|
||||
user interfaces and controls the server.
|
||||
|
|
@ -206,7 +206,7 @@ full-screen mode or quitting the viewer. Alternatively, you can operate `vncview
|
|||
through the terminal. Enter [command]#vncviewer -h# on the command line to list `vncviewer`pass:attributes[{blank}]'s parameters.
|
||||
|
||||
[[installing-vncviewer]]
|
||||
===== Installing VNC Viewer
|
||||
=== Installing VNC Viewer
|
||||
|
||||
To install the [application]*TigerVNC* client, [command]#vncviewer#pass:attributes[{blank}]>, issue the following command as `root`:
|
||||
|
||||
|
|
@ -216,7 +216,7 @@ To install the [application]*TigerVNC* client, [command]#vncviewer#pass:attribut
|
|||
----
|
||||
|
||||
[[s6-connecting-vnc-viewer]]
|
||||
===== Connecting to VNC Server
|
||||
=== Connecting to VNC Server
|
||||
|
||||
Once the VNC server is configured, you can connect to it from any VNC viewer.
|
||||
In order to do so, issue the [command]#vncviewer# command in the following format:
|
||||
|
|
@ -245,7 +245,7 @@ the command looks as follows:
|
|||
====
|
||||
|
||||
[[sec-Configuring_the_Firewall_for_VNC]]
|
||||
====== Configuring the Firewall for VNC
|
||||
==== Configuring the Firewall for VNC
|
||||
|
||||
When using a non-encrypted connection, `firewalld` might
|
||||
block the connection. To allow `firewalld` to pass the VNC packets, you can open specific ports to `TCP` traffic. When using the [option]`-via` option, traffic is redirected over `SSH` which is enabled by default in `firewalld`.
|
||||
|
|
@ -325,7 +325,7 @@ A port can be removed using the [command]#firewall-cmd --zone=pass:attributes[{b
|
|||
For more information on opening and closing ports in `firewalld`, see the link:++https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/++[Red{nbsp}Hat Enterprise{nbsp}Linux{nbsp}7 Security Guide].
|
||||
|
||||
[[s1-using_ssh]]
|
||||
===== Connecting to VNC Server Using SSH
|
||||
=== Connecting to VNC Server Using SSH
|
||||
|
||||
*VNC* is a clear text network protocol with no security against possible attacks on the communication. To make the communication secure, you can encrypt your server-client connection by using the [option]`-via` option. This will create an `SSH` tunnel between the VNC server and the client.
|
||||
|
||||
|
|
@ -372,7 +372,7 @@ This will stop `vncserver` from accepting connections from anything but the loca
|
|||
For more information on using `SSH`, see xref:OpenSSH.adoc#ch-OpenSSH[OpenSSH].
|
||||
|
||||
[[s9-additional-sources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
|
||||
For more information about TigerVNC, see the resources listed below.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
== Infrastructure Services
|
||||
= Infrastructure Services
|
||||
|
||||
This part provides information on how to configure services and daemons, configure authentication, and enable remote logins.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-Manually_Upgrading_the_Kernel]]
|
||||
=== Manually Upgrading the Kernel
|
||||
= Manually Upgrading the Kernel
|
||||
indexterm:[kernel,upgrading the kernel]indexterm:[kernel,package]indexterm:[kernel,RPM package]indexterm:[package,kernel RPM]
|
||||
The {MAJOROS} kernel is custom-built by the {MAJOROS} kernel team to ensure its integrity and compatibility with supported hardware. Before a kernel is released, it must first pass a rigorous set of quality assurance tests.
|
||||
|
||||
|
|
@ -23,7 +23,7 @@ indexterm:[kernel,installing kernel packages]
|
|||
For more information on installing kernel packages with [application]*DNF*, see xref:../package-management/DNF.adoc#sec-Updating_Packages[Updating Packages].
|
||||
|
||||
[[s1-kernel-packages]]
|
||||
==== Overview of Kernel Packages
|
||||
== Overview of Kernel Packages
|
||||
indexterm:[kernel,kernel packages]indexterm:[kernel package,kernel,for single, multicore and multiprocessor systems]indexterm:[packages,kernel,for single, multicore and multiprocessor systems]indexterm:[kernel package,kernel-devel,kernel headers and makefiles]indexterm:[packages,kernel-devel,kernel headers and makefiles]indexterm:[kernel package,kernel-headers,C header files files]indexterm:[packages,kernel-headers,C header files files]indexterm:[kernel package,linux-firmware,firmware files]indexterm:[packages,linux-firmware,firmware files]indexterm:[kernel package,perf,firmware files]indexterm:[packages,perf,firmware files]
|
||||
{MAJOROS} contains the following kernel packages:
|
||||
|
||||
|
|
@ -46,7 +46,7 @@ indexterm:[kernel,kernel packages]indexterm:[kernel package,kernel,for single, m
|
|||
* [package]*kernel-tools* — Contains tools for manipulating the Linux kernel and supporting documentation.
|
||||
|
||||
[[s1-kernel-preparing]]
|
||||
==== Preparing to Upgrade
|
||||
== Preparing to Upgrade
|
||||
indexterm:[boot media]indexterm:[kernel,upgrading,preparing]indexterm:[kernel upgrading,preparing]indexterm:[kernel,upgrading,working boot media]
|
||||
Before upgrading the kernel, it is recommended that you take some precautionary steps.
|
||||
|
||||
|
|
@ -133,7 +133,7 @@ kernel-modules.x86_64 4.0.4-301.fc22 @System
|
|||
From the output, determine which packages need to be downloaded for the kernel upgrade. For a single processor system, the only required package is the [package]*kernel* package. See xref:Manually_Upgrading_the_Kernel.adoc#s1-kernel-packages[Overview of Kernel Packages] for descriptions of the different packages.
|
||||
|
||||
[[s1-kernel-download]]
|
||||
==== Downloading the Upgraded Kernel
|
||||
== Downloading the Upgraded Kernel
|
||||
indexterm:[kernel,downloading]indexterm:[kernel,upgrade kernel available]indexterm:[kernel,upgrade kernel available,via Fedora Update System]indexterm:[kernel,upgrade kernel available,Security Advisories]
|
||||
There are several ways to determine if an updated kernel is available for the system.
|
||||
|
||||
|
|
@ -147,7 +147,7 @@ dnf check-update --enablerepo=updates-testing
|
|||
To install the kernel manually, continue to xref:Manually_Upgrading_the_Kernel.adoc#s1-kernel-perform-upgrade[Performing the Upgrade].
|
||||
|
||||
[[s1-kernel-perform-upgrade]]
|
||||
==== Performing the Upgrade
|
||||
== Performing the Upgrade
|
||||
indexterm:[kernel,performing kernel upgrade]
|
||||
After retrieving all of the necessary packages, it is time to upgrade the existing kernel.
|
||||
|
||||
|
|
@ -169,7 +169,7 @@ At a shell prompt, change to the directory that contains the kernel RPM packages
|
|||
The next step is to verify that the initial RAM disk image has been created. See xref:Manually_Upgrading_the_Kernel.adoc#sec-Verifying_the_Initial_RAM_Disk_Image[Verifying the Initial RAM Disk Image] for details.
|
||||
|
||||
[[sec-Verifying_the_Initial_RAM_Disk_Image]]
|
||||
==== Verifying the Initial RAM Disk Image
|
||||
== Verifying the Initial RAM Disk Image
|
||||
indexterm:[initial RAM disk image,verifying]
|
||||
The job of the initial RAM disk image is to preload the block device modules, such as for IDE, SCSI or RAID, so that the root file system, on which those modules normally reside, can then be accessed and mounted. On {MAJOROSVER} systems, whenever a new kernel is installed using either the [application]*DNF*, [application]*PackageKit*, or [application]*RPM* package manager, the [application]*Dracut* utility is always called by the installation scripts to create an _initramfs_ (initial RAM disk image).
|
||||
|
||||
|
|
@ -285,7 +285,7 @@ On IBM eServer System i machines, the initial RAM disk and kernel files are comb
|
|||
The _kernel_version_ should match the version of the kernel just installed.
|
||||
|
||||
[[s1-kernel-boot-loader]]
|
||||
==== Verifying the Boot Loader
|
||||
== Verifying the Boot Loader
|
||||
indexterm:[boot loader,verifying]
|
||||
When you install a kernel using [command]#rpm#, the kernel package creates an entry in the boot loader configuration file for that new kernel. However, [command]#rpm# does *not* configure the new kernel to boot as the default kernel. You must do this manually when installing a new kernel with [command]#rpm#.
|
||||
|
||||
|
|
@ -307,7 +307,7 @@ In the following table, find your system's architecture to determine the boot lo
|
|||
|===
|
||||
|
||||
[[s3-kernel-boot-loader-grub]]
|
||||
===== Configuring the GRUB 2 Boot Loader
|
||||
=== Configuring the GRUB 2 Boot Loader
|
||||
indexterm:[GRUB 2 boot loader,configuring]indexterm:[GRUB 2 boot loader,configuration file]
|
||||
{MAJOROSVER} is distributed with GRUB 2, which reads its configuration from the `/boot/grub2/grub.cfg` file. This file is generated by the [application]*grub2-mkconfig* utility based on Linux kernels located in the `/boot` directory, template files located in `/etc/grub.d/`, and custom settings in the `/etc/default/grub` file and is automatically updated each time you install a new kernel from an RPM package. To update this configuration file manually, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -362,7 +362,7 @@ If you set the [option]`GRUB_TIMEOUT` option in the `/etc/default/grub` file to
|
|||
====
|
||||
|
||||
[[s2-kernel-boot-loader-iseries]]
|
||||
===== Configuring the OS/400 Boot Loader
|
||||
=== Configuring the OS/400 Boot Loader
|
||||
indexterm:[OS/400 boot loader,configuring]indexterm:[OS/400 boot loader,configuration file]
|
||||
The `/boot/vmlinitrd-_kernel-version_pass:attributes[{blank}]` file is installed when you upgrade the kernel. However, you must use the [command]#dd# command to configure the system to boot the new kernel.
|
||||
|
||||
|
|
@ -378,7 +378,7 @@ The `/boot/vmlinitrd-_kernel-version_pass:attributes[{blank}]` file is installed
|
|||
Begin testing the new kernel by rebooting the computer and watching the messages to ensure that the hardware is detected properly.
|
||||
|
||||
[[s2-kernel-boot-loader-pseries]]
|
||||
===== Configuring the YABOOT Boot Loader
|
||||
=== Configuring the YABOOT Boot Loader
|
||||
|
||||
IBM eServer System p uses YABOOT as its boot loader. YABOOT uses `/etc/aboot.conf` as its configuration file. Confirm that the file contains an `image` section with the same version as the [package]*kernel* package just installed, and likewise for the `initramfs` image:
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-Working_with_Kernel_Modules]]
|
||||
=== Working with Kernel Modules
|
||||
= Working with Kernel Modules
|
||||
indexterm:[kernel module,definition]indexterm:[module,kernel module]indexterm:[drivers,kernel module]
|
||||
The Linux kernel is modular, which means it can extend its capabilities through the use of dynamically-loaded _kernel modules_. A kernel module can provide:
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ For more information on installing packages with DNF, see xref:../package-manage
|
|||
====
|
||||
|
||||
[[sec-Listing_Currently-Loaded_Modules]]
|
||||
==== Listing Currently-Loaded Modules
|
||||
== Listing Currently-Loaded Modules
|
||||
indexterm:[kernel module,listing,currently loaded modules]indexterm:[kernel module,utilities,lsmod]indexterm:[lsmod,kernel module]
|
||||
You can list all kernel modules that are currently loaded into the kernel by running the [command]#lsmod# command, for example:
|
||||
|
||||
|
|
@ -93,7 +93,7 @@ indexterm:[kernel module,files,/proc/modules]
|
|||
Finally, note that [command]#lsmod# output is less verbose and considerably easier to read than the content of the `/proc/modules` pseudo-file.
|
||||
|
||||
[[sec-Displaying_Information_About_a_Module]]
|
||||
==== Displaying Information About a Module
|
||||
== Displaying Information About a Module
|
||||
indexterm:[kernel module,listing,module information]indexterm:[kernel module,utilities,modinfo]indexterm:[modinfo,kernel module]
|
||||
You can display detailed information about a kernel module by running the [command]#modinfo{nbsp}pass:attributes[{blank}]_module_name_pass:attributes[{blank}]# command.
|
||||
|
||||
|
|
@ -196,7 +196,7 @@ parm: WriteProtectNVM:Write-protect NVM [WARNING: disabling this can l
|
|||
====
|
||||
|
||||
[[sec-Loading_a_Module]]
|
||||
==== Loading a Module
|
||||
== Loading a Module
|
||||
indexterm:[kernel module,loading,for the current session]indexterm:[kernel module,utilities,modprobe]indexterm:[modprobe,kernel module]
|
||||
To load a kernel module, run [command]#modprobe _module_name_pass:attributes[{blank}]# as `root`. For example, to load the `wacom` module, run:
|
||||
|
||||
|
|
@ -240,7 +240,7 @@ Although the [command]#insmod# command can also be used to load kernel modules,
|
|||
====
|
||||
|
||||
[[sec-Unloading_a_Module]]
|
||||
==== Unloading a Module
|
||||
== Unloading a Module
|
||||
indexterm:[kernel module,unloading]indexterm:[kernel module,utilities,modprobe]indexterm:[modprobe,kernel module]
|
||||
You can unload a kernel module by running [command]#modprobe -r _module_name_pass:attributes[{blank}]# as `root`. For example, assuming that the `wacom` module is already loaded into the kernel, you can unload it by running:
|
||||
|
||||
|
|
@ -300,7 +300,7 @@ Although the [command]#rmmod# command can be used to unload kernel modules, it i
|
|||
====
|
||||
|
||||
[[sec-Setting_Module_Parameters]]
|
||||
==== Setting Module Parameters
|
||||
== Setting Module Parameters
|
||||
indexterm:[module parameters,kernel module]indexterm:[kernel module,module parameters,supplying]
|
||||
Like the kernel itself, modules can also take parameters that change their behavior. Most of the time, the default ones work well, but occasionally it is necessary or desirable to set custom parameters for a module. Because parameters cannot be dynamically set for a module that is already loaded into a running kernel, there are two different methods for setting them.
|
||||
|
||||
|
|
@ -361,7 +361,7 @@ Output would indicate that the module is already loaded into the kernel, in whic
|
|||
This example illustrates passing multiple values to a single parameter by separating them with commas and omitting any spaces between them.
|
||||
|
||||
[[sec-Persistent_Module_Loading]]
|
||||
==== Persistent Module Loading
|
||||
== Persistent Module Loading
|
||||
indexterm:[kernel module,loading,at the boot time]indexterm:[kernel module,directories,/etc/modules-load.d/]
|
||||
As shown in xref:Working_with_Kernel_Modules.adoc#ex-Listing_information_about_a_kernel_module_with_lsmod[Listing information about a kernel module with lsmod], many kernel modules are loaded automatically at boot time. You can specify additional modules to be loaded by the `systemd-modules-load.service` daemon by creating a `pass:attributes[{blank}]_program_.conf` file in the `/etc/modules-load.d/` directory, where _program_ is any descriptive name of your choice. The files in `/etc/modules-load.d/` are text files that list the modules to be loaded, one per line.
|
||||
|
||||
|
|
@ -381,14 +381,14 @@ virtio-net
|
|||
See the `modules-load.d(5)` and `systemd-modules-load.service(8)` man pages for more information.
|
||||
|
||||
[[sect-signing-kernel-modules-for-secure-boot]]
|
||||
==== Signing Kernel Modules for Secure Boot
|
||||
== Signing Kernel Modules for Secure Boot
|
||||
|
||||
Fedora includes support for the UEFI Secure Boot feature, which means that Fedora can be installed and run on systems where UEFI Secure Boot is enabled. footnote:[Fedora does not require the use of Secure Boot on UEFI systems.] When Secure Boot is enabled, the EFI operating system boot loaders, the Fedora kernel, and all kernel modules must be signed with a private key and authenticated with the corresponding public key. The Fedora distribution includes signed boot loaders, signed kernels, and signed kernel modules. In addition, the signed first-stage boot loader and the signed kernel include embedded Fedora public keys. These signed executable binaries and embedded keys enable Fedora to install, boot, and run with the Microsoft UEFI Secure Boot CA keys that are provided by the UEFI firmware on systems that support UEFI Secure Boot.footnote:[Not all UEFI-based systems include support for Secure Boot.]
|
||||
|
||||
The information provided in the following sections describes steps necessary to enable you to self-sign privately built kernel modules for use with Fedora on UEFI-based systems where Secure Boot is enabled. These sections also provide an overview of available options for getting your public key onto the target system where you want to deploy your kernel module.
|
||||
|
||||
[[sect-prerequisites]]
|
||||
===== Prerequisites
|
||||
=== Prerequisites
|
||||
|
||||
In order to enable signing of externally built modules, the tools listed in the following table are required to be installed on the system.
|
||||
|
||||
|
|
@ -413,12 +413,12 @@ Note that the build system, where you build and sign your kernel module, does no
|
|||
====
|
||||
|
||||
[[sect-kernel-module-authentication]]
|
||||
===== Kernel Module Authentication
|
||||
=== Kernel Module Authentication
|
||||
|
||||
In Fedora, when a kernel module is loaded, the module's signature is checked using the public X.509 keys on the kernel's system key ring, excluding those keys that are on the kernel's system black list key ring.
|
||||
|
||||
[[sect-sources-for-public-keys-used-to-authenticate-kernel-modules]]
|
||||
====== Sources For Public Keys Used To Authenticate Kernel Modules
|
||||
==== Sources For Public Keys Used To Authenticate Kernel Modules
|
||||
|
||||
During boot, the kernel loads X.509 keys into the system key ring or the system black list key ring from a set of persistent key stores as shown in xref:Working_with_Kernel_Modules.adoc#table-sources-for-system-key-rings[Sources For System Key Rings]
|
||||
|
||||
|
|
@ -476,7 +476,7 @@ The following is abbreviated example output from a Fedora system where UEFI Secu
|
|||
The above output shows the addition of two keys from the UEFI Secure Boot "db" keys plus the `Fedora Secure Boot CA` which is embedded in the `shim.efi` boot loader.
|
||||
|
||||
[[sect-kernel-module-authentication-requirements]]
|
||||
====== Kernel Module Authentication Requirements
|
||||
==== Kernel Module Authentication Requirements
|
||||
|
||||
If UEFI Secure Boot is enabled or if the [option]`module.sig_enforce` kernel parameter has been specified, then only signed kernel modules that are authenticated using a key on the system key ring can be successfully loaded.footnote:[Provided that the public key is not on the system black list key ring.] If UEFI Secure Boot is disabled and if the [option]`module.sig_enforce` kernel parameter has not been specified, then unsigned kernel modules and signed kernel modules without a public key can be successfully loaded. This is summarized in xref:Working_with_Kernel_Modules.adoc#table-kernel-module-authentication-requirements-for-loading[Kernel Module Authentication Requirements for Loading].
|
||||
|
||||
|
|
@ -500,7 +500,7 @@ If UEFI Secure Boot is enabled or if the [option]`module.sig_enforce` kernel par
|
|||
Subsequent sections will describe how to generate a public and private X.509 key pair, how to use the private key to sign a kernel module, and how to enroll the public key into a source for the system key ring.
|
||||
|
||||
[[sect-generating-a-public-private-x509-key-pair]]
|
||||
===== Generating a Public and Private X.509 Key Pair
|
||||
=== Generating a Public and Private X.509 Key Pair
|
||||
|
||||
You need to generate a public and private X.509 key pair that will be used to sign a kernel module after it has been built. The corresponding public key will be used to authenticate the kernel module when it is loaded.
|
||||
|
||||
|
|
@ -549,17 +549,17 @@ Take proper care to guard the contents of your private key. In the wrong hands,
|
|||
====
|
||||
|
||||
[[sect-enrolling-public-key-on-target-system]]
|
||||
===== Enrolling Public Key on Target System
|
||||
=== Enrolling Public Key on Target System
|
||||
|
||||
When Fedora boots on a UEFI-based system with Secure Boot enabled, all keys that are in the Secure Boot db key database, but not in the dbx database of revoked keys, are loaded onto the system keyring by the kernel. The system keyring is used to authenticate kernel modules.
|
||||
|
||||
[[sect-factory-firmware-image-including-public-key]]
|
||||
====== Factory Firmware Image Including Public Key
|
||||
==== Factory Firmware Image Including Public Key
|
||||
|
||||
To facilitate authentication of your kernel module on your systems, consider requesting your system vendor to incorporate your public key into the UEFI Secure Boot key database in their factory firmware image.
|
||||
|
||||
[[sect-executable-key-enrollment-image-adding-public-key]]
|
||||
====== Executable Key Enrollment Image Adding Public Key
|
||||
==== Executable Key Enrollment Image Adding Public Key
|
||||
|
||||
It is possible to add a key to an existing populated and active Secure Boot key database. This can be done by writing and providing an EFI executable *enrollment* image. Such an enrollment image contains a properly formed request to append a key to the Secure Boot key database. This request must include data that is properly signed by the private key that corresponds to a public key that is already in the system's Secure Boot Key Exchange Key (KEK) database. Additionally, this EFI image must be signed by a private key that corresponds to a public key that is already in the key database.
|
||||
|
||||
|
|
@ -568,7 +568,7 @@ It is also possible to write an enrollment image that runs under Fedora. However
|
|||
The construction of either type of key enrollment images requires assistance from the platform vendor.
|
||||
|
||||
[[sect-system-administrator-manually-adding-public-key-to-the-mok-list]]
|
||||
====== System Administrator Manually Adding Public Key to the MOK List
|
||||
==== System Administrator Manually Adding Public Key to the MOK List
|
||||
|
||||
The Machine Owner Key (MOK) facility is a feature that is supported by Fedora and can be used to augment the UEFI Secure Boot key database. When Fedora boots on a UEFI-enabled system with Secure Boot enabled, the keys on the MOK list are also added to the system keyring in addition to the keys from the key database. The MOK list keys are also stored persistently and securely in the same fashion as the Secure Boot key database keys, but these are two separate facilities. The MOK facility is supported by shim.efi, MokManager.efi, grubx64.efi, and the Fedora [command]#mokutil# utility.
|
||||
|
||||
|
|
@ -592,7 +592,7 @@ You will be asked to enter and confirm a password for this MOK enrollment reques
|
|||
Once a key is on the MOK list, it will be automatically propagated to the system key ring on this and subsequent boots when UEFI Secure Boot is enabled.
|
||||
|
||||
[[sect-signing-kernel-module-with-the-private-key]]
|
||||
===== Signing Kernel Module with the Private Key
|
||||
=== Signing Kernel Module with the Private Key
|
||||
|
||||
There are no extra steps required to prepare your kernel module for signing. You build your kernel module normally. Assuming an appropriate Makefile and corresponding sources, follow these steps to build your module and sign it:
|
||||
|
||||
|
|
@ -621,7 +621,7 @@ Note that this appended signature is not contained in an ELF image section and i
|
|||
Your kernel module is now ready for loading. Note that your signed kernel module is also loadable on systems where UEFI Secure Boot is disabled or on a non-UEFI system. That means you do not need to provide both a signed and unsigned version of your kernel module.
|
||||
|
||||
[[sect-loading-signed-kernel-module]]
|
||||
===== Loading Signed Kernel Module
|
||||
=== Loading Signed Kernel Module
|
||||
|
||||
Once your public key is enrolled and is in the system keyring, the normal kernel module loading mechanisms will work transparently. In the following example, you will use [command]#mokutil# to add your public key to the MOK list and you will manually load your kernel module with [command]#modprobe#.
|
||||
|
||||
|
|
@ -659,7 +659,7 @@ pass:quotes[_my_module_] 12425 0
|
|||
----
|
||||
|
||||
[[s1-kernel-modules-additional-resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
|
||||
For more information on kernel modules and their utilities, see the following resources.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,12 +3,12 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-Working_with_the_GRUB_2_Boot_Loader]]
|
||||
=== Working with the GRUB 2 Boot Loader
|
||||
= Working with the GRUB 2 Boot Loader
|
||||
indexterm:[GRUB 2,configuring GRUB 2]indexterm:[GRUB 2,reinstalling GRUB 2]indexterm:[GRUB 2,customizing GRUB 2]indexterm:[boot loader,GRUB 2 boot loader]
|
||||
{MAJOROSVER} is distributed with the GNU GRand Unified Boot loader (GRUB) version 2 boot loader, which allows the user to select an operating system or kernel to be loaded at system boot time. GRUB 2 also allows the user to pass arguments to the kernel.
|
||||
|
||||
[[sec-Introduction_to_GRUB_2]]
|
||||
==== Introduction to GRUB 2
|
||||
== Introduction to GRUB 2
|
||||
|
||||
GRUB 2 reads its configuration from the `/boot/grub2/grub.cfg` file on traditional BIOS-based machines and from the `/boot/efi/EFI/fedora/grub.cfg` file on UEFI machines. This file contains menu information.
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ For information on using [application]*Dracut*, see xref:Manually_Upgrading_the_
|
|||
====
|
||||
|
||||
[[sec-Configuring_the_GRUB_2_Boot_Loader]]
|
||||
==== Configuring the GRUB 2 Boot Loader
|
||||
== Configuring the GRUB 2 Boot Loader
|
||||
|
||||
Changes to the GRUB 2 menu can be made temporarily at boot time, made persistent for a single system while the system is running, or as part of making a new GRUB 2 configuration file.
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ Changes to the GRUB 2 menu can be made temporarily at boot time, made persistent
|
|||
* For information on making and customizing a GRUB 2 configuration file, see xref:Working_with_the_GRUB_2_Boot_Loader.adoc#sec-Customizing_the_GRUB_2_Configuration_File[Customizing the GRUB 2 Configuration File].
|
||||
|
||||
[[sec-Making_Temporary_Changes_to_a_GRUB_2_Menu]]
|
||||
==== Making Temporary Changes to a GRUB 2 Menu
|
||||
== Making Temporary Changes to a GRUB 2 Menu
|
||||
|
||||
[[proc-Making_Temporary_Changes_to_Kernel_Menu_Entry]]
|
||||
.Making Temporary Changes to a Kernel Menu Entry
|
||||
|
|
@ -92,7 +92,7 @@ The [option]`rhgb` and [option]`quiet` parameters can be removed in order to ena
|
|||
These settings are not persistent and apply only for a single boot. To make persistent changes to a menu entry on a system, use the [command]#grubby# tool. See xref:Working_with_the_GRUB_2_Boot_Loader.adoc#bh-Adding_and_Removing_Arguments_from_a_GRUB_Menu_Entry[Adding and Removing Arguments from a GRUB Menu Entry] for more information on using [command]#grubby#.
|
||||
|
||||
[[sec-Making_Persistent_Changes_to_a_GRUB_2_Menu_Using_the_grubby_Tool]]
|
||||
==== Making Persistent Changes to a GRUB 2 Menu Using the grubby Tool
|
||||
== Making Persistent Changes to a GRUB 2 Menu Using the grubby Tool
|
||||
|
||||
The [command]#grubby# tool can be used to read information from, and make persistent changes to, the `grub.cfg` file. It enables, for example, changing GRUB menu entries to specify what arguments to pass to a kernel on system start and changing the default kernel.
|
||||
|
||||
|
|
@ -200,7 +200,7 @@ title=Fedora (4.2.0-1.fc23.x86_64) 23 (Workstation Edition)
|
|||
See the `grubby(8)` manual page for more command options.
|
||||
|
||||
[[sec-Customizing_the_GRUB_2_Configuration_File]]
|
||||
==== Customizing the GRUB 2 Configuration File
|
||||
== Customizing the GRUB 2 Configuration File
|
||||
|
||||
GRUB 2 scripts search the user's computer and build a boot menu based on what operating systems the scripts find. To reflect the latest system boot options, the boot menu is rebuilt automatically when the kernel is updated or a new kernel is added.
|
||||
|
||||
|
|
@ -228,7 +228,7 @@ With the [option]`GRUB_TIMEOUT` key set to `0` in the `/etc/default/grub` file,
|
|||
====
|
||||
|
||||
[[sec-Changing_the_Default_Boot_Entry]]
|
||||
===== Changing the Default Boot Entry
|
||||
=== Changing the Default Boot Entry
|
||||
|
||||
By default, the key for the `GRUB_DEFAULT` directive in the `/etc/default/grub` file is the word `saved`. This instructs GRUB 2 to load the kernel specified by the [option]`saved_entry` directive in the GRUB 2 environment file, located at `/boot/grub2/grubenv`. You can set another GRUB record to be the default, using the [command]#grub2-set-default# command, which will update the GRUB 2 environment file.
|
||||
|
||||
|
|
@ -282,7 +282,7 @@ Changes to `/etc/default/grub` require rebuilding the `grub.cfg` file as follows
|
|||
----
|
||||
|
||||
[[sec-Editing_a_Menu_Entry]]
|
||||
===== Editing a Menu Entry
|
||||
=== Editing a Menu Entry
|
||||
|
||||
If required to prepare a new GRUB 2 file with different parameters, edit the values of the `GRUB_CMDLINE_LINUX` key in the `/etc/default/grub` file. Note that you can specify multiple parameters for the `GRUB_CMDLINE_LINUX` key. For example:
|
||||
|
||||
|
|
@ -309,7 +309,7 @@ Changes to `/etc/default/grub` require rebuilding the `grub.cfg` file as follows
|
|||
----
|
||||
|
||||
[[sec-Adding_a_new_Entry]]
|
||||
===== Adding a new Entry
|
||||
=== Adding a new Entry
|
||||
|
||||
When executing the [command]#grub2-mkconfig# command, GRUB 2 searches for Linux kernels and other operating systems based on the files located in the `/etc/grub.d/` directory. The `/etc/grub.d/10_linux` script searches for installed Linux kernels on the same partition. The `/etc/grub.d/30_os-prober` script searches for other operating systems. Menu entries are also automatically added to the boot menu when updating the kernel.
|
||||
|
||||
|
|
@ -333,7 +333,7 @@ This file can be edited or copied. Note that as a minimum, a valid menu entry mu
|
|||
----
|
||||
|
||||
[[sec-Using_only_a_Custom_Menu]]
|
||||
===== Creating a Custom Menu
|
||||
=== Creating a Custom Menu
|
||||
|
||||
If you do not want menu entries to be updated automatically, you can create a custom menu.
|
||||
|
||||
|
|
@ -426,7 +426,7 @@ Alternatively, if you want to keep the files in the `/etc/grub2.d/` directory, m
|
|||
----
|
||||
|
||||
[[sec-GRUB_2_Password_Protection]]
|
||||
==== GRUB 2 Password Protection
|
||||
== GRUB 2 Password Protection
|
||||
|
||||
GRUB 2 supports both plain-text and encrypted passwords in the GRUB 2 template files. To enable the use of passwords, specify a superuser who can reach the protected entries. Other users can be specified to access these entries as well. Menu entries can be password-protected for booting by adding one or more users to the menu entry as described in xref:Working_with_the_GRUB_2_Boot_Loader.adoc#sec-Setting_Up_Users_and_Password_Protection_Specifying_Menu_Entries[Setting Up Users and Password Protection, Specifying Menu Entries]. To use encrypted passwords, see xref:Working_with_the_GRUB_2_Boot_Loader.adoc#sec-Password_Encryption[Password Encryption].
|
||||
|
||||
|
|
@ -440,7 +440,7 @@ If you do not use the correct format for the menu, or modify the configuration i
|
|||
All menu entries can be password-protected against changes by setting superusers, which can be done in the `/etc/grub.d/00_header` or the `/etc/grub.d/01_users` file. The `00_header` file is very complicated and, if possible, avoid making modifications in this file. Menu entries should be placed in the `/etc/grub.d/40_custom` and users in the `/etc/grub.d/01_users` file. The `01_users` file is generated by the installation application [application]*anaconda* when a grub boot loader password is used in a [application]*kickstart* template (but it should be created and used it if it does not exist). Examples in this section adopt this policy.
|
||||
|
||||
[[sec-Setting_Up_Users_and_Password_Protection_Specifying_Menu_Entries]]
|
||||
===== Setting Up Users and Password Protection, Specifying Menu Entries
|
||||
=== Setting Up Users and Password Protection, Specifying Menu Entries
|
||||
|
||||
. To specify a superuser, add the following lines in the `/etc/grub.d/01_users` file, where `john` is the name of the user designated as the superuser, and `johnspassword` is the superuser's password:
|
||||
|
||||
|
|
@ -513,7 +513,7 @@ Rebuild the `grub.cfg` file by running the [command]#grub2-mkconfig -o# command
|
|||
----
|
||||
|
||||
[[sec-Password_Encryption]]
|
||||
===== Password Encryption
|
||||
=== Password Encryption
|
||||
|
||||
By default, passwords are saved in plain text in GRUB 2 scripts. Although the files cannot be accessed on boot without the correct password, security can be improved by encrypting the password using the [command]#grub2-mkpasswd-pbkdf2# command. This command converts a desired password into a long hash, which is placed in the GRUB 2 scripts instead of the plain-text password.
|
||||
|
||||
|
|
@ -540,7 +540,7 @@ password_pbkdf2 john grub.pbkdf2.sha512.10000.19074739ED80F115963D984BDCB35AA671
|
|||
----
|
||||
|
||||
[[sec-Reinstalling_GRUB_2]]
|
||||
==== Reinstalling GRUB 2
|
||||
== Reinstalling GRUB 2
|
||||
|
||||
Reinstalling GRUB 2 is a convenient way to fix certain problems usually caused by an incorrect installation of GRUB 2, missing files, or a broken system. Other reasons to reinstall GRUB 2 include the following:
|
||||
|
||||
|
|
@ -551,7 +551,7 @@ Reinstalling GRUB 2 is a convenient way to fix certain problems usually caused b
|
|||
* Adding the boot information to another drive.
|
||||
|
||||
[[sec-grub2-reinstall_on_BIOS-Based_Machines]]
|
||||
===== Reinstalling GRUB 2 on BIOS-Based Machines
|
||||
=== Reinstalling GRUB 2 on BIOS-Based Machines
|
||||
|
||||
When using the [command]#grub2-install# command, the boot information is updated and missing files are restored. Note that the files are restored only if they are not corrupted.
|
||||
|
||||
|
|
@ -563,7 +563,7 @@ Use the [command]#grub2-install _device_pass:attributes[{blank}]# command to rei
|
|||
----
|
||||
|
||||
[[sec-grub2-reinstall_on_UEFI-Based_Machines]]
|
||||
===== Reinstalling GRUB 2 on UEFI-Based Machines
|
||||
=== Reinstalling GRUB 2 on UEFI-Based Machines
|
||||
|
||||
When using the [command]#dnf reinstall grub2-efi shim# command, the boot information is updated and missing files are restored. Note that the files are restored only if they are not corrupted.
|
||||
|
||||
|
|
@ -575,7 +575,7 @@ Use the [command]#dnf reinstall grub2-efi shim# command to reinstall GRUB 2 if t
|
|||
----
|
||||
|
||||
[[sec-Resetting_and_Reinstalling_GRUB_2]]
|
||||
===== Resetting and Reinstalling GRUB 2
|
||||
=== Resetting and Reinstalling GRUB 2
|
||||
|
||||
This method completely removes all GRUB 2 configuration files and system settings. Apply this method to reset all configuration settings to their default values. Removing of the configuration files and subsequent reinstalling of GRUB 2 fixes failures caused by corrupted files and incorrect configuration. To do so, as `root`, follow these steps:
|
||||
|
||||
|
|
@ -609,12 +609,12 @@ This method completely removes all GRUB 2 configuration files and system setting
|
|||
. Now follow the procedure in xref:Working_with_the_GRUB_2_Boot_Loader.adoc#sec-Reinstalling_GRUB_2[Reinstalling GRUB 2] to restore GRUB2 on the `/boot/` partition.
|
||||
|
||||
[[sec-GRUB_2_over_a_Serial_Console]]
|
||||
==== GRUB 2 over a Serial Console
|
||||
== GRUB 2 over a Serial Console
|
||||
|
||||
If you use computers with no display or keyboard, it can be very useful to control the machines through serial communications.
|
||||
|
||||
[[sec-Configuring_the_GRUB_2_Menu]]
|
||||
===== Configuring the GRUB 2 Menu
|
||||
=== Configuring the GRUB 2 Menu
|
||||
|
||||
To set the system to use a serial terminal only during a single boot process, when the GRUB 2 boot menu appears, move the cursor to the kernel you want to start, and press the kbd:[e] key to edit the kernel parameters. Remove the `rhgb` and `quit` parameters and add console parameters at the end of the `linux16` line as follows:
|
||||
|
||||
|
|
@ -677,7 +677,7 @@ For more information on serial console settings, see xref:Working_with_the_GRUB_
|
|||
====
|
||||
|
||||
[[sec-Using_screen_to_Connect_to_the_Serial_Console]]
|
||||
===== Using screen to Connect to the Serial Console
|
||||
=== Using screen to Connect to the Serial Console
|
||||
|
||||
The [application]*screen* tool serves as a capable serial terminal. To install it, run as `root`:
|
||||
|
||||
|
|
@ -707,14 +707,14 @@ To end the session in [application]*screen*, press kbd:[Ctrl]+kbd:[a], type `:qu
|
|||
See the `screen(1)` manual page for additional options and detailed information.
|
||||
|
||||
[[sec-Terminal_Menu_Editing_During_Boot]]
|
||||
==== Terminal Menu Editing During Boot
|
||||
== Terminal Menu Editing During Boot
|
||||
|
||||
Menu entries can be modified and arguments passed to the kernel on boot. This is done using the menu entry editor interface, which is triggered when pressing the kbd:[e] key on a selected menu entry in the boot loader menu. The kbd:[Esc] key discards any changes and reloads the standard menu interface. The kbd:[c] key loads the command line interface.
|
||||
|
||||
The command line interface is the most basic GRUB interface, but it is also the one that grants the most control. The command line makes it possible to type any relevant GRUB commands followed by the kbd:[Enter] key to execute them. This interface features some advanced features similar to [application]*shell*, including kbd:[Tab] key completion based on context, and kbd:[Ctrl + a] to move to the beginning of a line and kbd:[Ctrl + e] to move to the end of a line. In addition, the kbd:[arrow], kbd:[Home], kbd:[End], and kbd:[Delete] keys work as they do in the bash shell.
|
||||
|
||||
[[sec-Booting_to_Rescue_Mode]]
|
||||
===== Booting to Rescue Mode
|
||||
=== Booting to Rescue Mode
|
||||
|
||||
Rescue mode provides a convenient single-user environment and allows you to repair your system in situations when it is unable to complete a normal booting process. In rescue mode, the system attempts to mount all local file systems and start some important system services, but it does not activate network interfaces or allow more users to be logged into the system at the same time. In Fedora, rescue mode is equivalent to single user mode and requires the `root` password.
|
||||
|
||||
|
|
@ -734,7 +734,7 @@ Note that equivalent parameters, `1`, `s`, and `single`, can be passed to the ke
|
|||
. Press kbd:[Ctrl + x] to boot the system with the parameter.
|
||||
|
||||
[[sec-Booting_to_Emergency_Mode]]
|
||||
===== Booting to Emergency Mode
|
||||
=== Booting to Emergency Mode
|
||||
|
||||
Emergency mode provides the most minimal environment possible and allows you to repair your system even in situations when the system is unable to enter rescue mode. In emergency mode, the system mounts the `root` file system only for reading, does not attempt to mount any other local file systems, does not activate network interfaces, and only starts few essential services. In Fedora, emergency mode requires the `root` password.
|
||||
|
||||
|
|
@ -754,7 +754,7 @@ Note that equivalent parameters, `emergency` and `-b`, can be passed to the kern
|
|||
. Press kbd:[Ctrl + x] to boot the system with the parameter.
|
||||
|
||||
[[sec-Changing_and_Resetting_the_Root_Password]]
|
||||
===== Changing and Resetting the Root Password
|
||||
=== Changing and Resetting the Root Password
|
||||
|
||||
Setting up the `root` password is a mandatory part of the Fedora installation. If you forget or lose the `root` password it is possible to reset it, however users who are members of the wheel group can change the `root` password as follows:
|
||||
|
||||
|
|
@ -910,7 +910,7 @@ Enforcing
|
|||
----
|
||||
|
||||
[[sec-UEFI_Secure_Boot]]
|
||||
==== UEFI Secure Boot
|
||||
== UEFI Secure Boot
|
||||
|
||||
The Secure Boot technology ensures that the system firmware checks whether the system boot loader is signed with a cryptographic key authorized by a database contained in the firmware. With signature verification in the next-stage boot loader, kernel, and, potentially, user space, it is possible to prevent the execution of unsigned code.
|
||||
|
||||
|
|
@ -927,14 +927,14 @@ Secure Boot is the boot path validation component of the Unified Extensible Firm
|
|||
UEFI Secure Boot does not prevent the installation or removal of second-stage boot loaders, nor require explicit user confirmation of such changes. Signatures are verified during booting, not when the boot loader is installed or updated. Therefore, UEFI Secure Boot does not stop boot path manipulations, it simplifies the detection of changes and prevents the system from executing a modified boot path once such a modification has occurred.
|
||||
|
||||
[[sec-UEFI_Secure_Boot_Support_in_Fedora]]
|
||||
===== UEFI Secure Boot Support in Fedora
|
||||
=== UEFI Secure Boot Support in Fedora
|
||||
|
||||
{MAJOROS} includes support for the UEFI Secure Boot feature, which means that {MAJOROS} can be installed and run on systems where UEFI Secure Boot is enabled. On UEFI-based systems with the Secure Boot technology enabled, all drivers that are loaded must be signed with a valid certificate, otherwise the system will not accept them. All drivers provided by Red{nbsp}Hat are signed by the UEFI CA certificate.
|
||||
|
||||
If you want to load externally built drivers — drivers that are not provided on the {MAJOROS}{nbsp}Linux DVD — you must make sure these drivers are signed as well.
|
||||
|
||||
[[sec-Working_with_the_GRUB_2_Boot_Loader-Additional_Resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
|
||||
Please see the following resources for more information on the GRUB 2 boot loader:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
== Kernel, Module and Driver Configuration
|
||||
= Kernel, Module and Driver Configuration
|
||||
|
||||
This part covers various tools that assist administrators with kernel customization.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-Automating_System_Tasks]]
|
||||
=== Automating System Tasks
|
||||
= Automating System Tasks
|
||||
indexterm:[Automated Tasks]
|
||||
Tasks, also known as _jobs_, can be configured to run automatically within a specified period of time, on a specified date, or when the system load average decreases below 0.8.
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ Every utility is intended for scheduling a different job type: while Cron and An
|
|||
{MAJOROS} supports the use of `systemd.timer` for executing a job at a specific time. See man `systemd.timer(5)` for more information.
|
||||
|
||||
[[s1-autotasks-cron-anacron]]
|
||||
==== Cron and Anacron
|
||||
== Cron and Anacron
|
||||
indexterm:[anacron]indexterm:[cron]
|
||||
Both Cron and Anacron are daemons that can schedule execution of recurring tasks to a certain point in time defined by the exact time, day of the month, month, day of the week, and week.
|
||||
|
||||
|
|
@ -25,7 +25,7 @@ Cron jobs can run as often as every minute. However, the utility assumes that th
|
|||
On the other hand, Anacron remembers the scheduled jobs if the system is not running at the time when the job is scheduled. The job is then executed as soon as the system is up. However, Anacron can only run a job once a day.
|
||||
|
||||
[[sect-Cron-Installing]]
|
||||
===== Installing Cron and Anacron
|
||||
=== Installing Cron and Anacron
|
||||
|
||||
To install Cron and Anacron, you need to install the [package]*cronie* package with Cron and the [package]*cronie-anacron* package with Anacron ([package]*cronie-anacron* is a sub-package of [package]*cronie*).
|
||||
|
||||
|
|
@ -55,12 +55,12 @@ For example, to install both Cron and Anacron, type the following at a shell pro
|
|||
For more information on how to install new packages in {MAJOROS}, see xref:../package-management/DNF.adoc#sec-Installing[Installing Packages].
|
||||
|
||||
[[sect-Cron-Running]]
|
||||
===== Running the Crond Service
|
||||
=== Running the Crond Service
|
||||
|
||||
The cron and anacron jobs are both picked by the `crond` service. This section provides information on how to start, stop, and restart the `crond` service, and shows how to configure it to start automatically at boot time.
|
||||
|
||||
[[sect-Cron-service]]
|
||||
====== Starting and Stopping the Cron Service
|
||||
==== Starting and Stopping the Cron Service
|
||||
|
||||
To determine if the service is running, use the following command:
|
||||
|
||||
|
|
@ -84,7 +84,7 @@ To configure the service to start automatically at boot time, use the following
|
|||
----
|
||||
|
||||
[[sect-Crond_Stopping]]
|
||||
====== Stopping the Cron Service
|
||||
==== Stopping the Cron Service
|
||||
|
||||
To stop the `crond` service in the current session, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -101,7 +101,7 @@ To prevent the service from starting automatically at boot time, use the followi
|
|||
----
|
||||
|
||||
[[sect-Crond_Restarting]]
|
||||
====== Restarting the Cron Service
|
||||
==== Restarting the Cron Service
|
||||
|
||||
To restart the `crond` service, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -113,7 +113,7 @@ To restart the `crond` service, type the following at a shell prompt as `root`:
|
|||
This command stops the service and starts it again in quick succession.
|
||||
|
||||
[[s2-configuring-anacron-jobs]]
|
||||
===== Configuring Anacron Jobs
|
||||
=== Configuring Anacron Jobs
|
||||
indexterm:[anacron,anacron configuration file]indexterm:[anacrontab]indexterm:[anacron,user-defined tasks]indexterm:[/var/spool/anacron]
|
||||
The main configuration file to schedule jobs is the `/etc/anacrontab` file, which can be only accessed by the `root` user. The file contains the following:
|
||||
|
||||
|
|
@ -180,7 +180,7 @@ The command can be either a command such as [command]#ls /proc >> /tmp/proc# or
|
|||
Any lines that begin with a hash sign (#) are comments and are not processed.
|
||||
|
||||
[[s3-anacron-examples]]
|
||||
====== Examples of Anacron Jobs
|
||||
==== Examples of Anacron Jobs
|
||||
|
||||
The following example shows a simple `/etc/anacrontab` file:
|
||||
|
||||
|
|
@ -209,7 +209,7 @@ The second job executes the `weeklyjob.bash` script in the `/etc/` directory onc
|
|||
The third job runs a command, which writes the contents of `/proc` to the `/tmp/proc` file ([command]#ls /proc >> /tmp/proc#) once a month.
|
||||
|
||||
[[s2-configuring-cron-jobs]]
|
||||
===== Configuring Cron Jobs
|
||||
=== Configuring Cron Jobs
|
||||
indexterm:[cron,user-defined tasks]indexterm:[/var/spool/cron]indexterm:[cron,cron configuration file]indexterm:[crontab]
|
||||
The configuration file for cron jobs is `/etc/crontab`, which can be only modified by the `root` user. The file contains the following:
|
||||
|
||||
|
|
@ -285,7 +285,7 @@ The cron daemon checks the `/etc/anacrontab` file, the `/etc/crontab` file, the
|
|||
====
|
||||
|
||||
[[s2-autotasks-cron-access]]
|
||||
===== Controlling Access to Cron
|
||||
=== Controlling Access to Cron
|
||||
|
||||
To restrict the access to Cron, you can use the `/etc/cron.allow` and `/etc/cron.deny` files. These access control files use the same format with one user name on each line. Mind that no whitespace characters are permitted in either file.
|
||||
|
||||
|
|
@ -307,7 +307,7 @@ You can control the access also through Pluggable Authentication Modules (PAM).
|
|||
The forbidden jobs are logged in an appropriate log file or, when using [command]#crontab -e#, returned to the standard output. For more information, see the `access.conf.5` manual page.
|
||||
|
||||
[[s2-black-white-listing-of-cron-jobs]]
|
||||
===== Black and White Listing of Cron Jobs
|
||||
=== Black and White Listing of Cron Jobs
|
||||
|
||||
Black and white listing of jobs is used to define parts of a job that do not need to be executed. This is useful when calling the [application]*run-parts* script on a Cron directory, such as `/etc/cron.daily/`: if the user adds programs located in the directory to the job black list, the [application]*run-parts* script will not execute these programs.
|
||||
|
||||
|
|
@ -318,12 +318,12 @@ To define a white list, create a `jobs.allow` file.
|
|||
The principles of `jobs.deny` and `jobs.allow` are the same as those of `cron.deny` and `cron.allow` described in section xref:Automating_System_Tasks.adoc#s2-autotasks-cron-access[Controlling Access to Cron].
|
||||
|
||||
[[s1-autotasks-at-batch]]
|
||||
==== At and Batch
|
||||
== At and Batch
|
||||
indexterm:[at]indexterm:[batch]
|
||||
While Cron is used to schedule recurring tasks, the [application]*At* utility is used to schedule a one-time task at a specific time and the [application]*Batch* utility is used to schedule a one-time task to be executed when the system load average drops below 0.8.
|
||||
|
||||
[[sect-At_and_Batch_Installation]]
|
||||
===== Installing At and Batch
|
||||
=== Installing At and Batch
|
||||
|
||||
To determine if the [package]*at* package is already installed on your system, issue the following command:
|
||||
|
||||
|
|
@ -351,12 +351,12 @@ For example, to install both At and Batch, type the following at a shell prompt:
|
|||
For more information on how to install new packages in {MAJOROS}, see xref:../package-management/DNF.adoc#sec-Installing[Installing Packages].
|
||||
|
||||
[[sect-Atd-Running]]
|
||||
===== Running the At Service
|
||||
=== Running the At Service
|
||||
|
||||
The At and Batch jobs are both picked by the `atd` service. This section provides information on how to start, stop, and restart the `atd` service, and shows how to configure it to start automatically at boot time.
|
||||
|
||||
[[sect-Atd-service]]
|
||||
====== Starting and Stopping the At Service
|
||||
==== Starting and Stopping the At Service
|
||||
|
||||
To determine if the service is running, use the following command:
|
||||
|
||||
|
|
@ -387,7 +387,7 @@ It is recommended that you configure your system to start the `atd` service auto
|
|||
====
|
||||
|
||||
[[sect-Atd_Stopping]]
|
||||
====== Stopping the At Service
|
||||
==== Stopping the At Service
|
||||
|
||||
To stop the `atd` service, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -404,7 +404,7 @@ To prevent the service from starting automatically at boot time, use the followi
|
|||
----
|
||||
|
||||
[[sect-Atd_Restarting]]
|
||||
====== Restarting the At Service
|
||||
==== Restarting the At Service
|
||||
|
||||
To restart the `atd` service, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -416,7 +416,7 @@ To restart the `atd` service, type the following at a shell prompt as `root`:
|
|||
This command stops the service and starts it again in quick succession.
|
||||
|
||||
[[s2-autotasks-at-configuring]]
|
||||
===== Configuring an At Job
|
||||
=== Configuring an At Job
|
||||
|
||||
To schedule a one-time job for a specific time with the [application]*At* utility, do the following:
|
||||
|
||||
|
|
@ -459,7 +459,7 @@ To view the list of pending jobs, use the [command]#atq# command. See xref:Autom
|
|||
You can also restrict the usage of the [command]#at# command. For more information, see xref:Automating_System_Tasks.adoc#s2-autotasks-at-batch-controlling-access[Controlling Access to At and Batch] for details.
|
||||
|
||||
[[s2-autotasks-batch-configuring]]
|
||||
===== Configuring a Batch Job
|
||||
=== Configuring a Batch Job
|
||||
|
||||
The [application]*Batch* application executes the defined one-time tasks when the system load average decreases below 0.8.
|
||||
|
||||
|
|
@ -484,12 +484,12 @@ To view the list of pending jobs, use the [command]#atq# command. See xref:Autom
|
|||
You can also restrict the usage of the [command]#batch# command. For more information, see xref:Automating_System_Tasks.adoc#s2-autotasks-at-batch-controlling-access[Controlling Access to At and Batch] for details.
|
||||
|
||||
[[s2-autotasks-at-batch-viewing]]
|
||||
===== Viewing Pending Jobs
|
||||
=== Viewing Pending Jobs
|
||||
|
||||
To view the pending [command]#At# and [command]#Batch# jobs, run the [command]#atq# command. The [command]#atq# command displays a list of pending jobs, with each job on a separate line. Each line follows the job number, date, hour, job class, and user name format. Users can only view their own jobs. If the `root` user executes the [command]#atq# command, all jobs for all users are displayed.
|
||||
|
||||
[[s2-autotasks-commandline-options]]
|
||||
===== Additional Command Line Options
|
||||
=== Additional Command Line Options
|
||||
|
||||
Additional command line options for [command]#at# and [command]#batch# include the following:
|
||||
|
||||
|
|
@ -505,7 +505,7 @@ Additional command line options for [command]#at# and [command]#batch# include t
|
|||
|===
|
||||
|
||||
[[s2-autotasks-at-batch-controlling-access]]
|
||||
===== Controlling Access to At and Batch
|
||||
=== Controlling Access to At and Batch
|
||||
|
||||
You can restrict the access to the [command]#at# and [command]#batch# commands using the `/etc/at.allow` and `/etc/at.deny` files. These access control files use the same format defining one user name on each line. Mind that no whitespace are permitted in either file.
|
||||
|
||||
|
|
@ -518,7 +518,7 @@ The [command]#at# daemon ([command]#atd#) does not have to be restarted if the a
|
|||
The `root` user can always execute [command]#at# and [command]#batch# commands, regardless of the content of the access control files.
|
||||
|
||||
[[s1-autotasks-additional-resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
indexterm:[cron,additional resources]indexterm:[at,additional resources]indexterm:[batch,additional resources]
|
||||
To learn more about configuring automated tasks, see the following installed documentation:
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-OProfile]]
|
||||
=== OProfile
|
||||
= OProfile
|
||||
indexterm:[system analysis,OProfile,OProfile]indexterm:[OProfile]
|
||||
OProfile is a low overhead, system-wide performance monitoring tool. It uses the performance monitoring hardware on the processor to retrieve information about the kernel and executables on the system, such as when memory is referenced, the number of L2 cache requests, and the number of hardware interrupts received. On a {MAJOROS} system, the `oprofile` package must be installed to use this tool.
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ Be aware of the following limitations when using OProfile:
|
|||
* *Non-CPU-limited performance problems* — OProfile is oriented to finding problems with CPU-limited processes. OProfile does not identify processes that are asleep because they are waiting on locks or for some other event to occur (for example an I/O device to finish an operation).
|
||||
|
||||
[[s1-oprofile-overview-tools]]
|
||||
==== Overview of Tools
|
||||
== Overview of Tools
|
||||
indexterm:[OProfile,overview of tools]
|
||||
xref:OProfile.adoc#tb-oprofile-tools[OProfile Commands] provides a brief overview of the most commonly used tools provided with the `oprofile` package.
|
||||
|
||||
|
|
@ -47,7 +47,7 @@ xref:OProfile.adoc#tb-oprofile-tools[OProfile Commands] provides a brief overvie
|
|||
|===
|
||||
|
||||
[[s2-operf_vs_opcontrol]]
|
||||
===== operf vs. opcontrol
|
||||
=== operf vs. opcontrol
|
||||
|
||||
There are two mutually exclusive methods for collecting profiling data with OProfile. You can either use the newer and preferred [command]#operf# or the [command]#opcontrol# tool.
|
||||
|
||||
|
|
@ -62,7 +62,7 @@ This mode consists of the [command]#opcontrol# shell script, the `oprofiled` dae
|
|||
Before OProfile can be run in legacy mode, it must be configured as shown in xref:OProfile.adoc#s1-oprofile-configuring[Configuring OProfile Using Legacy Mode]. These settings are then applied when starting OProfile (xref:OProfile.adoc#s1-oprofile-starting[Starting and Stopping OProfile Using Legacy Mode]).
|
||||
|
||||
[[s1-using-operf]]
|
||||
==== Using operf
|
||||
== Using operf
|
||||
|
||||
[command]#operf# is the recommended profiling mode that does not require initial setup before starting. All settings are specified as command-line options and there is no separate command to start the profiling process. To stop [command]#operf#, press Ctrl+C. The typical [command]#operf# command syntax looks as follows:
|
||||
|
||||
|
|
@ -100,7 +100,7 @@ When running [command]#operf# [option]`--system-wide`, it is recommended that yo
|
|||
====
|
||||
|
||||
[[s2-operf-kernel]]
|
||||
===== Specifying the Kernel
|
||||
=== Specifying the Kernel
|
||||
|
||||
To monitor the kernel, execute the following command:
|
||||
|
||||
|
|
@ -112,7 +112,7 @@ operf --vmlinux=pass:quotes[_vmlinux_path_]
|
|||
With this option, you can specify a path to a vmlinux file that matches the running kernel. Kernel samples will be attributed to this binary, allowing post-processing tools to attribute samples to the appropriate kernel symbols. If this option is not specified, all kernel samples will be attributed to a pseudo binary named "no-vmlinux".
|
||||
|
||||
[[s2-operf-events]]
|
||||
===== Setting Events to Monitor
|
||||
=== Setting Events to Monitor
|
||||
|
||||
Most processors contain counters, which are used by OProfile to monitor specific events. As shown in xref:OProfile.adoc#tb-oprofile-processors[OProfile Processors and Counters], the number of counters available depends on the processor.
|
||||
|
||||
|
|
@ -191,19 +191,19 @@ The events available vary depending on the processor type. When no event specifi
|
|||
----
|
||||
|
||||
[[s2-operf-categorization]]
|
||||
===== Categorization of Samples
|
||||
=== Categorization of Samples
|
||||
|
||||
The [option]`--separate-thread` option categorizes samples by thread group ID (tgid) and thread ID (tid). This is useful for seeing per-thread samples in multi-threaded applications. When used in conjunction with the [option]`--system-wide` option, [option]`--separate-thread` is also useful for seeing per-process (i.e., per-thread group) samples for the case where multiple processes are executing the same program during a profiling run.
|
||||
|
||||
The [option]`--separate-cpu` option categorizes samples by CPU.
|
||||
|
||||
[[s1-oprofile-configuring]]
|
||||
==== Configuring OProfile Using Legacy Mode
|
||||
== Configuring OProfile Using Legacy Mode
|
||||
indexterm:[OProfile,configuring]indexterm:[OProfile,opcontrol]indexterm:[opcontrol,OProfile]
|
||||
Before OProfile can be run in legacy mode, it must be configured. At a minimum, selecting to monitor the kernel (or selecting not to monitor the kernel) is required. The following sections describe how to use the [command]#opcontrol# utility to configure OProfile. As the [command]#opcontrol# commands are executed, the setup options are saved to the `/root/.oprofile/daemonrc` file.
|
||||
|
||||
[[s2-oprofile-kernel]]
|
||||
===== Specifying the Kernel
|
||||
=== Specifying the Kernel
|
||||
indexterm:[OProfile,monitoring the kernel]
|
||||
First, configure whether OProfile should monitor the kernel. This is the only configuration option that is required before starting OProfile. All others are optional.
|
||||
|
||||
|
|
@ -232,7 +232,7 @@ This command also loads the `oprofile` kernel module, if it is not already loade
|
|||
Setting whether samples should be collected within the kernel only changes what data is collected, not how or where the collected data is stored. To generate different sample files for the kernel and application libraries, see xref:OProfile.adoc#s2-oprofile-starting-separate[Separating Kernel and User-space Profiles].
|
||||
|
||||
[[s2-oprofile-events]]
|
||||
===== Setting Events to Monitor
|
||||
=== Setting Events to Monitor
|
||||
indexterm:[OProfile,events,setting]
|
||||
Most processors contain _counters_, which are used by OProfile to monitor specific events. As shown in xref:OProfile.adoc#tb-oprofile-processors[OProfile Processors and Counters], the number of counters available depends on the processor.
|
||||
|
||||
|
|
@ -348,7 +348,7 @@ To set the event for each configurable counter via the command line, use [comman
|
|||
Replace _event-name_ with the exact name of the event from [command]#ophelp#, and replace _sample-rate_ with the number of events between samples.
|
||||
|
||||
[[s3-oprofile-events-sampling]]
|
||||
====== Sampling Rate
|
||||
==== Sampling Rate
|
||||
indexterm:[OProfile,events,sampling rate]
|
||||
By default, a time-based event set is selected. It creates a sample every 100,000 clock cycles per processor. If the timer interrupt is used, the timer is set to the respective rate and is not user-settable. If the `cpu_type` is not `timer`, each event can have a _sampling rate_ set for it. The sampling rate is the number of events between each sample snapshot.
|
||||
|
||||
|
|
@ -369,7 +369,7 @@ Be extremely careful when setting sampling rates. Sampling too frequently can ov
|
|||
====
|
||||
|
||||
[[s3-oprofile-events-unit-masks]]
|
||||
====== Unit Masks
|
||||
==== Unit Masks
|
||||
indexterm:[OProfile,unit mask]
|
||||
Some user performance monitoring events may also require unit masks to further define the event.
|
||||
|
||||
|
|
@ -382,7 +382,7 @@ Unit masks for each event are listed with the [command]#ophelp# command. The val
|
|||
Note that on certain architectures, there can be multiple unit masks with the same hexadecimal value. In that case they have to be specified by their names only.
|
||||
|
||||
[[s2-oprofile-starting-separate]]
|
||||
===== Separating Kernel and User-space Profiles
|
||||
=== Separating Kernel and User-space Profiles
|
||||
indexterm:[OProfile,configuring,separating profiles]
|
||||
By default, kernel mode and user mode information is gathered for each event. To configure OProfile to ignore events in kernel mode for a specific counter, execute the following command:
|
||||
|
||||
|
|
@ -435,7 +435,7 @@ These configuration changes will take effect when the OProfile profiler is resta
|
|||
====
|
||||
|
||||
[[s1-oprofile-starting]]
|
||||
==== Starting and Stopping OProfile Using Legacy Mode
|
||||
== Starting and Stopping OProfile Using Legacy Mode
|
||||
indexterm:[OProfile,starting]
|
||||
To start monitoring the system with OProfile, execute the following command as root:
|
||||
indexterm:[OProfile,opcontrol,--start]
|
||||
|
|
@ -481,7 +481,7 @@ To stop the profiler, execute the following command as root:
|
|||
----
|
||||
|
||||
[[s1-oprofile-saving-data]]
|
||||
==== Saving Data in Legacy Mode
|
||||
== Saving Data in Legacy Mode
|
||||
indexterm:[OProfile,saving data]
|
||||
Sometimes it is useful to save samples at a specific time. For example, when profiling an executable, it may be useful to gather different samples based on different input data sets. If the number of events to be monitored exceeds the number of counters available for the processor, multiple runs of OProfile can be used to collect data, saving the sample data to different files each time.
|
||||
|
||||
|
|
@ -496,7 +496,7 @@ The command creates the directory `/var/lib/oprofile/samples/pass:attributes[{bl
|
|||
To specify the session directory to hold the sample data, use the [option]`--session-dir` option. If not specified, the data is saved in the `oprofile_data/` directory on the current path.
|
||||
|
||||
[[s1-oprofile-analyzing-data]]
|
||||
==== Analyzing the Data
|
||||
== Analyzing the Data
|
||||
indexterm:[OProfile,reading data]
|
||||
The same OProfile post-processing tools are used whether you collect your profile with [command]#operf# or [command]#opcontrol# in legacy mode.
|
||||
|
||||
|
|
@ -533,7 +533,7 @@ The executable being profiled must be used with these tools to analyze the data.
|
|||
Samples for each executable are written to a single sample file. Samples from each dynamically linked library are also written to a single sample file. While OProfile is running, if the executable being monitored changes and a sample file for the executable exists, the existing sample file is automatically deleted. Thus, if the existing sample file is needed, it must be backed up, along with the executable used to create it before replacing the executable with a new version. The OProfile analysis tools use the executable file that created the samples during analysis. If the executable changes, the analysis tools will be unable to analyze the associated samples. See xref:OProfile.adoc#s1-oprofile-saving-data[Saving Data in Legacy Mode] for details on how to back up the sample file.
|
||||
|
||||
[[s2-oprofile-reading-opreport]]
|
||||
===== Using [command]#opreport#
|
||||
=== Using [command]#opreport#
|
||||
indexterm:[OProfile,opreport]indexterm:[opreport,OProfile]
|
||||
The [command]#opreport# tool provides an overview of all the executables being profiled. The following is part of a sample output from the [command]#opreport# command:
|
||||
|
||||
|
|
@ -573,7 +573,7 @@ Each executable is listed on its own line. The first column is the number of sam
|
|||
See the `opreport(1)` manual page for a list of available command-line options, such as the [option]`-r` option used to sort the output from the executable with the smallest number of samples to the one with the largest number of samples. You can also use the [option]`-t` or [option]`--threshold` option to trim the output of [command]#opcontrol#.
|
||||
|
||||
[[s2-oprofile-reading-opreport-single]]
|
||||
===== Using opreport on a Single Executable
|
||||
=== Using opreport on a Single Executable
|
||||
indexterm:[OProfile,opreport,on a single executable]indexterm:[opreport,OProfile]
|
||||
To retrieve more detailed profiled information about a specific executable, use the [command]#opreport# command:
|
||||
|
||||
|
|
@ -676,7 +676,7 @@ The data is the same as the [option]`-l` option except that for each symbol, eac
|
|||
[option]`session`:pass:attributes[{blank}]_name_:: Here, you can specify the full path to the session, a directory relative to the `/var/lib/oprofile/samples/` directory, or if you are using [command]#operf#, a directory relative to `./oprofile_data/samples/`.
|
||||
|
||||
[[s2-oprofile-module-output]]
|
||||
===== Getting More Detailed Output on the Modules
|
||||
=== Getting More Detailed Output on the Modules
|
||||
indexterm:[OProfile,opreport]indexterm:[OProfile]
|
||||
OProfile collects data on a system-wide basis for kernel- and user-space code running on the machine. However, once a module is loaded into the kernel, the information about the origin of the kernel module is lost. The module could come from the `initrd` file on boot up, the directory with the various kernel modules, or a locally created kernel module. As a result, when OProfile records samples for a module, it just lists the samples for the modules for an executable in the root directory, but this is unlikely to be the place with the actual code for the module. You will need to take some steps to make sure that analysis tools get the proper executable.
|
||||
|
||||
|
|
@ -719,7 +719,7 @@ samples % symbol name
|
|||
----
|
||||
|
||||
[[s2-oprofile-reading-opannotate]]
|
||||
===== Using [command]#opannotate#
|
||||
=== Using [command]#opannotate#
|
||||
indexterm:[OProfile,opannotate]indexterm:[opannotate,OProfile]
|
||||
The [command]#opannotate# tool tries to match the samples for particular instructions to the corresponding lines in the source code. The resulting generated files should have the samples for the lines at the left. It also puts in a comment at the beginning of each function listing the total samples for the function.
|
||||
|
||||
|
|
@ -734,7 +734,7 @@ The general syntax for [command]#opannotate# is as follows:
|
|||
These command-line options are mandatory. Replace _src-dir_ with a path to the directory containing the source code and specify the executable to be analyzed. See the `opannotate(1)` manual page for a list of additional command line options.
|
||||
|
||||
[[s1-oprofile-dev-oprofile]]
|
||||
==== Understanding the /dev/oprofile/ directory
|
||||
== Understanding the /dev/oprofile/ directory
|
||||
indexterm:[OProfile,/dev/oprofile/]indexterm:[/dev/oprofile/]
|
||||
When using OProfile in legacy mode, the `/dev/oprofile/` directory is used to store the file system for OProfile. On the other hand, [command]#operf# does not require `/dev/oprofile/`. Use the [command]#cat# command to display the values of the virtual files in this file system. For example, the following command displays the type of processor OProfile detected:
|
||||
|
||||
|
|
@ -767,7 +767,7 @@ The values of these files can be retrieved with the [command]#cat# command. For
|
|||
----
|
||||
|
||||
[[s1-oprofile-example-usage]]
|
||||
==== Example Usage
|
||||
== Example Usage
|
||||
|
||||
While OProfile can be used by developers to analyze application performance, it can also be used by system administrators to perform system analysis. For example:
|
||||
|
||||
|
|
@ -776,12 +776,12 @@ While OProfile can be used by developers to analyze application performance, it
|
|||
* *Determine processor usage* — The `CPU_CLK_UNHALTED` event can be monitored to determine the processor load over a given period of time. This data can then be used to determine if additional processors or a faster processor might improve system performance.
|
||||
|
||||
[[s1-oprofile-java-support]]
|
||||
==== OProfile Support for Java
|
||||
== OProfile Support for Java
|
||||
indexterm:[OProfile,Java]
|
||||
OProfile allows you to profile dynamically compiled code (also known as "just-in-time" or JIT code) of the Java Virtual Machine (JVM). OProfile in {MAJOROSVER} includes built-in support for the JVM Tools Interface (JVMTI) agent library, which supports Java 1.5 and higher.
|
||||
|
||||
[[s1-oprofile-java-profiling]]
|
||||
===== Profiling Java Code
|
||||
=== Profiling Java Code
|
||||
|
||||
To profile JIT code from the Java Virtual Machine with the JVMTI agent, add the following to the JVM startup parameters:
|
||||
|
||||
|
|
@ -813,7 +813,7 @@ After successful setup, you can apply the standard profiling and analyzing tools
|
|||
To learn more about Java support in OProfile, see the OProfile Manual, which is linked from xref:OProfile.adoc#s1-oprofile_additional_resources[Additional Resources].
|
||||
|
||||
[[s1-oprofile-gui]]
|
||||
==== Graphical Interface
|
||||
== Graphical Interface
|
||||
indexterm:[oprof_start]
|
||||
Some OProfile preferences can be set with a graphical interface. Make sure you have the `oprofile-gui` package that provides the OProfile GUI installed on your system. To start the interface, execute the [command]#oprof_start# command as root at a shell prompt.
|
||||
|
||||
|
|
@ -850,7 +850,7 @@ To force data to be written to samples files as discussed in xref:OProfile.adoc#
|
|||
To start OProfile from the graphical interface, click btn:[Start]. To stop the profiler, click btn:[Stop]. Exiting the application does not stop OProfile from sampling.
|
||||
|
||||
[[s1-oprofile-and-systemtap]]
|
||||
==== OProfile and SystemTap
|
||||
== OProfile and SystemTap
|
||||
indexterm:[OProfile,SystemTap]
|
||||
SystemTap is a tracing and probing tool that allows users to study and monitor the activities of the operating system in fine detail. It provides information similar to the output of tools like [command]#netstat#, [command]#ps#, [command]#top#, and [command]#iostat#pass:attributes[{blank}]; however, SystemTap is designed to provide more filtering and analysis options for the collected information.
|
||||
|
||||
|
|
@ -861,7 +861,7 @@ You might want to use SystemTap when instrumenting specific places in code. Beca
|
|||
For more information on SystemTap, see xref:OProfile.adoc#br-oprofile_online_documentation[Online Documentation] for the relevant SystemTap documentation.
|
||||
|
||||
[[s1-oprofile_additional_resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
indexterm:[OProfile,additional resources]
|
||||
To learn more about OProfile and how to configure it, see the following resources.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,16 +3,16 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-System_Monitoring_Tools]]
|
||||
=== System Monitoring Tools
|
||||
= System Monitoring Tools
|
||||
indexterm:[system information,gathering]indexterm:[information,about your system]
|
||||
In order to configure the system, system administrators often need to determine the amount of free memory, how much free disk space is available, how the hard drive is partitioned, or what processes are running.
|
||||
|
||||
[[s1-sysinfo-system-processes]]
|
||||
==== Viewing System Processes
|
||||
== Viewing System Processes
|
||||
indexterm:[system information,processes]indexterm:[processes]
|
||||
|
||||
[[s2-sysinfo-system-processes-ps]]
|
||||
===== Using the ps Command
|
||||
=== Using the ps Command
|
||||
indexterm:[ps]
|
||||
The [command]#ps# command allows you to display information about running processes. It produces a static list, that is, a snapshot of what is running when you execute the command. If you want a constantly updated list of running processes, use the [command]#top# command or the [application]*System Monitor* application instead.
|
||||
|
||||
|
|
@ -69,7 +69,7 @@ You can also use the [command]#ps# command in a combination with [command]#grep#
|
|||
For a complete list of available command line options, refer to the *ps*(1) manual page.
|
||||
|
||||
[[s2-sysinfo-system-processes-top]]
|
||||
===== Using the top Command
|
||||
=== Using the top Command
|
||||
indexterm:[system information,processes,currently running]indexterm:[top]
|
||||
The [command]#top# command displays a real-time list of processes that are running on the system. It also displays additional information about the system uptime, current CPU and memory usage, or total number of running processes, and allows you to perform actions such as sorting the list or killing a process.
|
||||
|
||||
|
|
@ -129,7 +129,7 @@ xref:System_Monitoring_Tools.adoc#interactive-top-command[Interactive top comman
|
|||
|===
|
||||
|
||||
[[s2-sysinfo-system-processes-system_monitor]]
|
||||
===== Using the System Monitor Tool
|
||||
=== Using the System Monitor Tool
|
||||
indexterm:[gnome-system-monitor]indexterm:[System Monitor]
|
||||
The `Processes` tab of the [application]*System Monitor* tool allows you to view, search for, change the priority of, and kill processes from the graphical user interface.
|
||||
|
||||
|
|
@ -175,11 +175,11 @@ Additionally, various options in the Edit menu allows you to:
|
|||
You can also end a process by selecting it from the list and clicking the btn:[End Process] button.
|
||||
|
||||
[[s1-sysinfo-memory-usage]]
|
||||
==== Viewing Memory Usage
|
||||
== Viewing Memory Usage
|
||||
indexterm:[system information,memory usage]indexterm:[memory usage]indexterm:[RAM]
|
||||
|
||||
[[s2-sysinfo-memory-usage-free]]
|
||||
===== Using the free Command
|
||||
=== Using the free Command
|
||||
indexterm:[free]
|
||||
The [command]#free# command allows you to display the amount of free and used memory on the system. To do so, type the following at a shell prompt:
|
||||
|
||||
|
|
@ -218,7 +218,7 @@ Swap: 1503 82 1421
|
|||
For a complete list of available command line options, refer to the *free*(1) manual page.
|
||||
|
||||
[[s2-sysinfo-memory-usage-system_monitor]]
|
||||
===== Using the System Monitor Tool
|
||||
=== Using the System Monitor Tool
|
||||
indexterm:[gnome-system-monitor]indexterm:[System Monitor]
|
||||
The `Resources` tab of the [application]*System Monitor* tool allows you to view the amount of free and used memory on the system.
|
||||
|
||||
|
|
@ -232,11 +232,11 @@ image::system-monitor-resources.png[The Resources tab of the System Monitor appl
|
|||
In the `Memory and Swap History` section, the [application]*System Monitor* tool displays a graphical representation of the memory and swap usage history, as well as the total amount of the physical memory (`Memory`) and swap space (`Swap`) and how much of it is in use.
|
||||
|
||||
[[s1-sysinfo-cpu]]
|
||||
==== Viewing CPU Usage
|
||||
== Viewing CPU Usage
|
||||
indexterm:[system information,cpu usage]indexterm:[CPU usage]
|
||||
|
||||
[[s2-sysinfo-cpu-system_monitor]]
|
||||
===== Using the System Monitor Tool
|
||||
=== Using the System Monitor Tool
|
||||
indexterm:[gnome-system-monitor]indexterm:[System Monitor]
|
||||
The `Resources` tab of the [application]*System Monitor* tool allows you to view the current CPU usage on the system.
|
||||
|
||||
|
|
@ -250,11 +250,11 @@ image::system-monitor-resources.png[The Resources tab of the System Monitor appl
|
|||
In the `CPU History` section, the [application]*System Monitor* tool displays a graphical representation of the CPU usage history and shows the percentage of how much CPU is currently in use.
|
||||
|
||||
[[s1-sysinfo-filesystems]]
|
||||
==== Viewing Block Devices and File Systems
|
||||
== Viewing Block Devices and File Systems
|
||||
indexterm:[system information,file systems]indexterm:[file systems]
|
||||
|
||||
[[s2-sysinfo-filesystems-lsblk]]
|
||||
===== Using the lsblk Command
|
||||
=== Using the lsblk Command
|
||||
indexterm:[lsblk]
|
||||
The [command]#lsblk# command allows you to display a list of available block devices. To do so, type the following at a shell prompt:
|
||||
|
||||
|
|
@ -299,7 +299,7 @@ vg_fedora-lv_root (dm-1) 253:1 0 18G 0 lvm /
|
|||
For a complete list of available command line options, refer to the *lsblk*(8) manual page.
|
||||
|
||||
[[s2-sysinfo-filesystems-blkid]]
|
||||
===== Using the blkid Command
|
||||
=== Using the blkid Command
|
||||
indexterm:[blkid]
|
||||
The [command]#blkid# command allows you to display information about available block devices. To do so, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -360,7 +360,7 @@ ID_PART_ENTRY_DISK=252:0
|
|||
For a complete list of available command line options, refer to the *blkid*(8) manual page.
|
||||
|
||||
[[s2-sysinfo-filesystems-partx]]
|
||||
===== Using the partx Command
|
||||
=== Using the partx Command
|
||||
indexterm:[partx]
|
||||
The [command]#partx# command allows you to display a list of disk partitions. To list the partition table of a particular disk, as `root`, run this command with the [option]`-s` option followed by the device name:
|
||||
|
||||
|
|
@ -381,7 +381,7 @@ NR START END SECTORS SIZE NAME UUID
|
|||
For a complete list of available command line options, refer to the *partx*(8) manual page.
|
||||
|
||||
[[s2-sysinfo-filesystems-findmnt]]
|
||||
===== Using the findmnt Command
|
||||
=== Using the findmnt Command
|
||||
indexterm:[findmnt]
|
||||
The [command]#findmnt# command allows you to display a list of currently mounted file systems. To do so, type the following at a shell prompt:
|
||||
|
||||
|
|
@ -463,7 +463,7 @@ TARGET SOURCE FSTYPE OPTIONS
|
|||
For a complete list of available command line options, refer to the *findmnt*(8) manual page.
|
||||
|
||||
[[s2-sysinfo-filesystems-df]]
|
||||
===== Using the df Command
|
||||
=== Using the df Command
|
||||
indexterm:[df]
|
||||
The [command]#df# command allows you to display a detailed report on the system's disk space usage. To do so, type the following at a shell prompt:
|
||||
|
||||
|
|
@ -514,7 +514,7 @@ Note that the `/dev/shm` entry represents the system's virtual memory file syste
|
|||
For a complete list of available command line options, refer to the *df*(1) manual page.
|
||||
|
||||
[[s2-sysinfo-filesystems-du]]
|
||||
===== Using the du Command
|
||||
=== Using the du Command
|
||||
indexterm:[du]
|
||||
The [command]#du# command allows you to displays the amount of space that is being used by files in a directory. To display the disk usage for each of the subdirectories in the current working directory, run the command with no additional command line options:
|
||||
|
||||
|
|
@ -574,7 +574,7 @@ For example:
|
|||
For a complete list of available command line options, refer to the *du*(1) manual page.
|
||||
|
||||
[[s2-sysinfo-filesystems-system_monitor]]
|
||||
===== Using the System Monitor Tool
|
||||
=== Using the System Monitor Tool
|
||||
indexterm:[gnome-system-monitor]indexterm:[System Monitor]
|
||||
The `File Systems` tab of the [application]*System Monitor* tool allows you to view file systems and disk space usage in the graphical user interface.
|
||||
|
||||
|
|
@ -588,11 +588,11 @@ image::system-monitor-file-systems.png[The File Systems tab of the System Monito
|
|||
For each listed file system, the [application]*System Monitor* tool displays the source device (`Device`), target mount point (`Directory`), and file system type (`Type`), as well as its size (`Total`) and how much space is free (`Free`), available (`Available`), and used (`Used`).
|
||||
|
||||
[[s1-sysinfo-hardware]]
|
||||
==== Viewing Hardware Information
|
||||
== Viewing Hardware Information
|
||||
indexterm:[system information,hardware]indexterm:[hardware,viewing]
|
||||
|
||||
[[s2-sysinfo-hardware-lspci]]
|
||||
===== Using the lspci Command
|
||||
=== Using the lspci Command
|
||||
indexterm:[lspci]
|
||||
The [command]#lspci# command lists all PCI devices that are present in the system:
|
||||
|
||||
|
|
@ -646,7 +646,7 @@ _[output truncated]_
|
|||
For a complete list of available command line options, refer to the *lspci*(8) manual page.
|
||||
|
||||
[[s2-sysinfo-hardware-lsusb]]
|
||||
===== Using the lsusb Command
|
||||
=== Using the lsusb Command
|
||||
indexterm:[lsusb]
|
||||
The [command]#lsusb# command allows you to display information about USB buses and devices that are attached to them. To list all USB devices that are in the system, type the following at a shell prompt:
|
||||
|
||||
|
|
@ -707,7 +707,7 @@ _[output truncated]_
|
|||
For a complete list of available command line options, refer to the *lsusb*(8) manual page.
|
||||
|
||||
[[s2-sysinfo-hardware-lspcmcia]]
|
||||
===== Using the lspcmcia Command
|
||||
=== Using the lspcmcia Command
|
||||
indexterm:[lspcmcia]
|
||||
The [command]#lspcmcia# command allows you to list all PCMCIA devices that are present in the system. To do so, type the following at a shell prompt:
|
||||
|
||||
|
|
@ -741,7 +741,7 @@ Socket 0 Bridge: [yenta_cardbus] (bus ID: 0000:15:00.0)
|
|||
For a complete list of available command line options, refer to the *pccardctl*(8) manual page.
|
||||
|
||||
[[s2-sysinfo-hardware-lscpu]]
|
||||
===== Using the lscpu Command
|
||||
=== Using the lscpu Command
|
||||
indexterm:[lscpu]
|
||||
The [command]#lscpu# command allows you to list information about CPUs that are present in the system, including the number of CPUs, their architecture, vendor, family, model, CPU caches, etc. To do so, type the following at a shell prompt:
|
||||
|
||||
|
|
@ -779,14 +779,14 @@ NUMA node0 CPU(s): 0-3
|
|||
For a complete list of available command line options, refer to the *lscpu*(1) manual page.
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP]]
|
||||
==== Monitoring Performance with Net-SNMP
|
||||
== Monitoring Performance with Net-SNMP
|
||||
|
||||
{MAJOROSVER} includes the [application]*Net-SNMP* software suite, which includes a flexible and extensible _Simple Network Management Protocol_ (*SNMP*) agent. This agent and its associated utilities can be used to provide performance data from a large number of systems to a variety of tools which support polling over the SNMP protocol.
|
||||
|
||||
This section provides information on configuring the Net-SNMP agent to securely provide performance data over the network, retrieving the data using the SNMP protocol, and extending the SNMP agent to provide custom performance metrics.
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Installing]]
|
||||
===== Installing Net-SNMP
|
||||
=== Installing Net-SNMP
|
||||
|
||||
The Net-SNMP software suite is available as a set of RPM packages in the {MAJOROS} software distribution. xref:System_Monitoring_Tools.adoc#tabl-System_Monitoring_Tools-Net-SNMP-Packages[Available Net-SNMP packages] summarizes each of the packages and their contents.
|
||||
|
||||
|
|
@ -819,12 +819,12 @@ For example, to install the SNMP Agent Daemon and SNMP clients used in the rest
|
|||
Note that you must have superuser privileges (that is, you must be logged in as `root`) to run this command. For more information on how to install new packages in {MAJOROS}, refer to xref:../package-management/DNF.adoc#sec-Installing[Installing Packages].
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Running]]
|
||||
===== Running the Net-SNMP Daemon
|
||||
=== Running the Net-SNMP Daemon
|
||||
|
||||
The [package]*net-snmp* package contains `snmpd`, the SNMP Agent Daemon. This section provides information on how to start, stop, and restart the `snmpd` service, and shows how to enable or disable it in the `multi-user` target unit. For more information on the concept of target units and how to manage system services in {MAJOROS} in general, refer to xref:../infrastructure-services/Services_and_Daemons.adoc#ch-Services_and_Daemons[Services and Daemons].
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Running-Starting]]
|
||||
====== Starting the Service
|
||||
==== Starting the Service
|
||||
|
||||
To run the `snmpd` service in the current session, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -843,7 +843,7 @@ To configure the service to be automatically started at boot time, use the follo
|
|||
This will enable the service in the `multi-user` target unit.
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Running-Stopping]]
|
||||
====== Stopping the Service
|
||||
==== Stopping the Service
|
||||
|
||||
To stop the running `snmpd` service, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -862,7 +862,7 @@ To disable starting the service at boot time, use the following command:
|
|||
This will disable the service in the `multi-user` target unit.
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Running-Restarting]]
|
||||
====== Restarting the Service
|
||||
==== Restarting the Service
|
||||
|
||||
To restart the running `snmpd` service, type the following at a shell prompt:
|
||||
|
||||
|
|
@ -881,7 +881,7 @@ This will stop the service and start it again in quick succession. To only reloa
|
|||
This will cause the running `snmpd` service to reload the configuration.
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Configuring]]
|
||||
===== Configuring Net-SNMP
|
||||
=== Configuring Net-SNMP
|
||||
|
||||
To change the Net-SNMP Agent Daemon configuration, edit the `/etc/snmp/snmpd.conf` configuration file. The default `snmpd.conf` file shipped with {MAJOROSVER} is heavily commented and serves as a good starting point for agent configuration.
|
||||
|
||||
|
|
@ -903,7 +903,7 @@ For any changes to the configuration file to take effect, force the `snmpd` serv
|
|||
====
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Configuring-System_Information]]
|
||||
====== Setting System Information
|
||||
==== Setting System Information
|
||||
|
||||
Net-SNMP provides some rudimentary system information via the `system` tree. For example, the following [command]#snmpwalk# command shows the `system` tree with a default agent configuration.
|
||||
|
||||
|
|
@ -939,7 +939,7 @@ SNMPv2-MIB::sysLocation.0 = STRING: Datacenter, Row 3, Rack 2
|
|||
----
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Configuring-Authentication]]
|
||||
====== Configuring Authentication
|
||||
==== Configuring Authentication
|
||||
|
||||
The Net-SNMP Agent Daemon supports all three versions of the SNMP protocol. The first two versions (1 and 2c) provide for simple authentication using a _community string_. This string is a shared secret between the agent and any client utilities. The string is passed in clear text over the network however and is not considered secure. Version 3 of the SNMP protocol supports user authentication and message encryption using a variety of protocols. The Net-SNMP agent also supports tunneling over SSH, TLS authentication with X.509 certificates, and Kerberos authentication.
|
||||
|
||||
|
|
@ -1025,14 +1025,14 @@ SNMPv2-MIB::sysDescr.0 = STRING: Linux localhost.localdomain 2.6.32-122.el6.x86_
|
|||
----
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Retrieving]]
|
||||
===== Retrieving Performance Data over SNMP
|
||||
=== Retrieving Performance Data over SNMP
|
||||
|
||||
The Net-SNMP Agent in {MAJOROS} provides a wide variety of performance information over the SNMP protocol. In addition, the agent can be queried for a listing of the installed RPM packages on the system, a listing of currently running processes on the system, or the network configuration of the system.
|
||||
|
||||
This section provides an overview of OIDs related to performance tuning available over SNMP. It assumes that the [package]*net-snmp-utils* package is installed and that the user is granted access to the SNMP tree as described in xref:System_Monitoring_Tools.adoc#sect-System_Monitoring_Tools-Net-SNMP-Configuring-Authentication[Configuring Authentication].
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Retrieving-Hardware]]
|
||||
====== Hardware Configuration
|
||||
==== Hardware Configuration
|
||||
|
||||
The `Host Resources MIB` included with Net-SNMP presents information about the current hardware and software configuration of a host to a client utility. xref:System_Monitoring_Tools.adoc#tabl-System_Monitoring_Tools-Net-SNMP-OIDs[Available OIDs] summarizes the different OIDs available under that MIB.
|
||||
|
||||
|
|
@ -1070,7 +1070,7 @@ SNMP table: HOST-RESOURCES-MIB::hrFSTable
|
|||
For more information about `HOST-RESOURCES-MIB`, see the `/usr/share/snmp/mibs/HOST-RESOURCES-MIB.txt` file.
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Retrieving-CPU]]
|
||||
====== CPU and Memory Information
|
||||
==== CPU and Memory Information
|
||||
|
||||
Most system performance data is available in the `UCD SNMP MIB`. The `systemStats` OID provides a number of counters around processor usage:
|
||||
|
||||
|
|
@ -1139,7 +1139,7 @@ SNMP table: UCD-SNMP-MIB::laTable
|
|||
----
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Retrieving-File_System]]
|
||||
====== File System and Disk Information
|
||||
==== File System and Disk Information
|
||||
|
||||
The `Host Resources MIB` provides information on file system size and usage. Each file system (and also each memory pool) has an entry in the `HOST-RESOURCES-MIB::hrStorageTable` table:
|
||||
|
||||
|
|
@ -1186,7 +1186,7 @@ SNMP table: UCD-DISKIO-MIB::diskIOTable
|
|||
----
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Retrieving-Network]]
|
||||
====== Network Information
|
||||
==== Network Information
|
||||
|
||||
Information on network devices is provided by the Interfaces MIB. `IF-MIB::ifTable` provides an SNMP table with an entry for each interface on the system, the configuration of the interface, and various packet counters for the interface. The following example shows the first few columns of `ifTable` on a system with two physical network interfaces:
|
||||
|
||||
|
|
@ -1220,14 +1220,14 @@ IF-MIB::ifInOctets.3 = Counter32: 0
|
|||
----
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Extending]]
|
||||
===== Extending Net-SNMP
|
||||
=== Extending Net-SNMP
|
||||
|
||||
The Net-SNMP Agent can be extended to provide application metrics in addition to raw system metrics. This allows for capacity planning as well as performance issue troubleshooting. For example, it may be helpful to know that an email system had a 5-minute load average of 15 while being tested, but it is more helpful to know that the email system has a load average of 15 while processing 80,000 messages a second. When application metrics are available via the same interface as the system metrics, this also allows for the visualization of the impact of different load scenarios on system performance (for example, each additional 10,000 messages increases the load average linearly until 100,000).
|
||||
|
||||
A number of the applications that ship with {MAJOROS} extend the Net-SNMP Agent to provide application metrics over SNMP. There are several ways to extend the agent for custom applications as well. This section describes extending the agent with shell scripts and Perl plug-ins. It assumes that the [package]*net-snmp-utils* and [package]*net-snmp-perl* packages are installed, and that the user is granted access to the SNMP tree as described in xref:System_Monitoring_Tools.adoc#sect-System_Monitoring_Tools-Net-SNMP-Configuring-Authentication[Configuring Authentication].
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Extending-Shell]]
|
||||
====== Extending Net-SNMP with Shell Scripts
|
||||
==== Extending Net-SNMP with Shell Scripts
|
||||
|
||||
The Net-SNMP Agent provides an extension MIB (`NET-SNMP-EXTEND-MIB`) that can be used to query arbitrary shell scripts. To specify the shell script to run, use the [option]`extend` directive in the `/etc/snmp/snmpd.conf` file. Once defined, the Agent will provide the exit code and any output of the command over SNMP. The example below demonstrates this mechanism with a script which determines the number of `httpd` processes in the process table.
|
||||
|
||||
|
|
@ -1338,7 +1338,7 @@ UCD-SNMP-MIB::memAvailReal.0 = INTEGER: 799664 kB
|
|||
----
|
||||
|
||||
[[sect-System_Monitoring_Tools-Net-SNMP-Extending-Perl]]
|
||||
====== Extending Net-SNMP with Perl
|
||||
==== Extending Net-SNMP with Perl
|
||||
|
||||
Executing shell scripts using the [option]`extend` directive is a fairly limited method for exposing custom application metrics over SNMP. The Net-SNMP Agent also provides an embedded Perl interface for exposing custom objects. The [package]*net-snmp-perl* package provides the `NetSNMP::agent` Perl module that is used to write embedded Perl plug-ins on {MAJOROS}.
|
||||
|
||||
|
|
@ -1473,12 +1473,12 @@ NET-SNMP-MIB::netSnmpPlaypen.1.1 = INTEGER: 8675309
|
|||
----
|
||||
|
||||
[[s1-sysinfo-additional-resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
|
||||
To learn more about gathering system information, refer to the following resources.
|
||||
|
||||
[[s2-sysinfo-installed-docs]]
|
||||
===== Installed Documentation
|
||||
=== Installed Documentation
|
||||
|
||||
* *ps*(1) — The manual page for the [command]#ps# command.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-Viewing_and_Managing_Log_Files]]
|
||||
=== Viewing and Managing Log Files
|
||||
= Viewing and Managing Log Files
|
||||
indexterm:[log files,System Log]indexterm:[log files,description]
|
||||
_Log files_ are files that contain messages about the system, including the kernel, services, and applications running on it. There are different log files for different information. For example, there is a default system log file, a log file just for security messages, and a log file for cron tasks.
|
||||
|
||||
|
|
@ -16,19 +16,19 @@ Log files can also be managed by the `journald` daemon – a component of `s
|
|||
By default, these two logging tools coexist on your system. The `journald` daemon is the primary tool for troubleshooting. It also provides additional data necessary for creating structured log messages. Data acquired by `journald` is forwarded into the `/run/systemd/journal/syslog` socket that may be used by `rsyslogd` to process the data further. However, [application]*rsyslog* does the actual integration by default via the `imjournal` input module, thus avoiding the aforementioned socket. You can also transfer data in the opposite direction, from `rsyslogd` to `journald` with use of `omjournal` module. See xref:Viewing_and_Managing_Log_Files.adoc#s1-interaction_of_rsyslog_and_journal[Interaction of Rsyslog and Journal] for further information. The integration enables maintaining text-based logs in a consistent format to ensure compatibility with possible applications or configurations dependent on `rsyslogd`. Also, you can maintain rsyslog messages in a structured format (see xref:Viewing_and_Managing_Log_Files.adoc#s1-structured_logging_with_rsyslog[Structured Logging with Rsyslog]).
|
||||
|
||||
[[s1-logfiles-locating]]
|
||||
==== Locating Log Files
|
||||
== Locating Log Files
|
||||
indexterm:[log files,locating]
|
||||
A list of log files maintained by `rsyslogd` can be found in the `/etc/rsyslog.conf` configuration file. Most log files are located in the `/var/log/` directory. Some applications such as [command]#httpd# and [command]#samba# have a directory within `/var/log/` for their log files.
|
||||
indexterm:[log files,rotating]indexterm:[logrotate]
|
||||
You may notice multiple files in the `/var/log/` directory with numbers after them (for example, `cron-20100906`). These numbers represent a time stamp that has been added to a rotated log file. Log files are rotated so their file sizes do not become too large. The `logrotate` package contains a cron task that automatically rotates log files according to the `/etc/logrotate.conf` configuration file and the configuration files in the `/etc/logrotate.d/` directory.
|
||||
|
||||
[[s1-basic_configuration_of_rsyslog]]
|
||||
==== Basic Configuration of Rsyslog
|
||||
== Basic Configuration of Rsyslog
|
||||
indexterm:[rsyslog,configuration]
|
||||
The main configuration file for [application]*rsyslog* is `/etc/rsyslog.conf`. Here, you can specify _global directives_, _modules_, and _rules_ that consist of _filter_ and _action_ parts. Also, you can add comments in the form of text following a hash sign (`#`).
|
||||
|
||||
[[s2-Filters]]
|
||||
===== Filters
|
||||
=== Filters
|
||||
indexterm:[rsyslog,filters]
|
||||
A rule is specified by a *filter* part, which selects a subset of syslog messages, and an *action* part, which specifies what to do with the selected messages. To define a rule in your `/etc/rsyslog.conf` configuration file, define both, a filter and an action, on one line and separate them with one or more spaces or tabs.
|
||||
|
||||
|
|
@ -191,7 +191,7 @@ if $programname == 'prog1' then {
|
|||
See xref:Viewing_and_Managing_Log_Files.adoc#brid-Log_Files-Resources-Online[Online Documentation] for more examples of various expression-based filters. RainerScript is the basis for [application]*rsyslog*pass:attributes[{blank}]'s new configuration format, see xref:Viewing_and_Managing_Log_Files.adoc#sec-using_the_new_configuration_format[Using the New Configuration Format]
|
||||
|
||||
[[s2-Actions]]
|
||||
===== Actions
|
||||
=== Actions
|
||||
indexterm:[rsyslog,actions]
|
||||
Actions specify what is to be done with the messages filtered out by an already-defined selector. The following are some of the actions you can define in your rule:
|
||||
|
||||
|
|
@ -456,7 +456,7 @@ A template must be defined before it is used in an action, otherwise it is ignor
|
|||
====
|
||||
|
||||
[[s2-Templates]]
|
||||
===== Templates
|
||||
=== Templates
|
||||
indexterm:[rsyslog,templates]
|
||||
Any output that is generated by [application]*rsyslog* can be modified and formatted according to your needs with the use of *templates*. To create a template use the following syntax in `/etc/rsyslog.conf`:
|
||||
|
||||
|
|
@ -638,7 +638,7 @@ $template dbFormat,"insert into SystemEvents (Message, Facility, FromHost, Prior
|
|||
----
|
||||
|
||||
[[s2-global_directives]]
|
||||
===== Global Directives
|
||||
=== Global Directives
|
||||
indexterm:[rsyslog,global directives]
|
||||
Global directives are configuration options that apply to the `rsyslogd` daemon. They usually specify a value for a specific predefined variable that affects the behavior of the `rsyslogd` daemon or a rule that follows. All of the global directives must start with a dollar sign (`$`). Only one directive can be specified per line. The following is an example of a global directive that specifies the maximum size of the syslog message queue:
|
||||
|
||||
|
|
@ -654,7 +654,7 @@ The default size defined for this directive (10,000 messages) can be overridden
|
|||
You can define multiple directives in your `/etc/rsyslog.conf` configuration file. A directive affects the behavior of all configuration options until another occurrence of that same directive is detected. Global directives can be used to configure actions, queues and for debugging. A comprehensive list of all available configuration directives can be found in xref:Viewing_and_Managing_Log_Files.adoc#brid-Log_Files-Resources-Online[Online Documentation]. Currently, a new configuration format has been developed that replaces the $-based syntax (see xref:Viewing_and_Managing_Log_Files.adoc#sec-using_the_new_configuration_format[Using the New Configuration Format]). However, classic global directives remain supported as a legacy format.
|
||||
|
||||
[[s2-log_rotation]]
|
||||
===== Log Rotation
|
||||
=== Log Rotation
|
||||
indexterm:[rsyslog,log rotation]
|
||||
The following is a sample `/etc/logrotate.conf` configuration file:
|
||||
|
||||
|
|
@ -727,7 +727,7 @@ The following is a list of some of the directives you can specify in your [appli
|
|||
For the full list of directives and various configuration options, see the `logrotate(5)` manual page.
|
||||
|
||||
[[sec-using_the_new_configuration_format]]
|
||||
==== Using the New Configuration Format
|
||||
== Using the New Configuration Format
|
||||
indexterm:[rsyslog,new configuration format]
|
||||
In [application]*rsyslog* version 6, a new configuration syntax was introduced. This new configuration format aims to be more powerful, more intuitive, and to prevent common mistakes by not permitting certain invalid constructs. The syntax enhancement is enabled by the new configuration processor that relies on RainerScript. The legacy format is still fully supported and it is used by default in the `/etc/rsyslog.conf` configuration file.
|
||||
|
||||
|
|
@ -757,7 +757,7 @@ input(type="imfile" file="/tmp/inputfile" tag="tag1:" statefile="inputfile-state
|
|||
This significantly reduces the number of parameters used in configuration, improves readability, and also provides higher execution speed. For more information on RainerScript statements and parameters see xref:Viewing_and_Managing_Log_Files.adoc#brid-Log_Files-Resources-Online[Online Documentation].
|
||||
|
||||
[[sec-Rulesets]]
|
||||
===== Rulesets
|
||||
=== Rulesets
|
||||
indexterm:[rsyslog,rulesets]
|
||||
Leaving special directives aside, [application]*rsyslog* handles messages as defined by *rules* that consist of a filter condition and an action to be performed if the condition is true. With a traditionally written `/etc/rsyslog.conf` file, all rules are evaluated in order of appearance for every input message. This process starts with the first rule and continues until all rules have been processed or until the message is discarded by one of the rules.
|
||||
|
||||
|
|
@ -831,14 +831,14 @@ Rulesets shown in the above example define log destinations for the remote input
|
|||
====
|
||||
|
||||
[[s2-compatibility_with_syslogd]]
|
||||
===== Compatibility with syslogd
|
||||
=== Compatibility with syslogd
|
||||
|
||||
From [application]*rsyslog* version 6, compatibility mode specified via the [option]`-c` option has been removed. Also, the syslogd-style command-line options are deprecated and configuring [application]*rsyslog* through these command-line options should be avoided. However, you can use several templates and directives to configure `rsyslogd` to emulate syslogd-like behavior.
|
||||
|
||||
For more information on various `rsyslogd` options, see the `rsyslogd(8)`pass:attributes[{blank}]manual page.
|
||||
|
||||
[[s1-working_with_queues_in_rsyslog]]
|
||||
==== Working with Queues in Rsyslog
|
||||
== Working with Queues in Rsyslog
|
||||
indexterm:[rsyslog,queues]
|
||||
Queues are used to pass content, mostly syslog messages, between components of [application]*rsyslog*. With queues, rsyslog is capable of processing multiple messages simultaneously and to apply several actions to a single message at once. The data flow inside [application]*rsyslog* can be illustrated as follows:
|
||||
|
||||
|
|
@ -869,7 +869,7 @@ If an output plug-in is unable to deliver a message, it is stored in the precedi
|
|||
====
|
||||
|
||||
[[s2-defining_queues]]
|
||||
===== Defining Queues
|
||||
=== Defining Queues
|
||||
|
||||
Based on where the messages are stored, there are several types of queues: *direct*, *in-memory*, *disk*, and *disk-assisted in-memory* queues that are most widely used. You can choose one of these types for the main message queue and also for action queues. Add the following into `/etc/rsyslog.conf`:
|
||||
|
||||
|
|
@ -1035,7 +1035,7 @@ $ActionQueueSaveOnShutdown on
|
|||
====
|
||||
|
||||
[[s2-managing_queues]]
|
||||
===== Managing Queues
|
||||
=== Managing Queues
|
||||
|
||||
All types of queues can be further configured to match your requirements. You can use several directives to modify both action queues and the main message queue. Currently, there are more than 20 queue parameters available, see xref:Viewing_and_Managing_Log_Files.adoc#brid-Log_Files-Resources-Online[Online Documentation]. Some of these settings are used commonly, others, such as worker thread management, provide closer control over the queue behavior and are reserved for advanced users. With advanced settings, you can optimize [application]*rsyslog*pass:attributes[{blank}]'s performance, schedule queuing, or modify the behavior of a queue on system shutdown.
|
||||
|
||||
|
|
@ -1149,7 +1149,7 @@ $pass:attributes[{blank}]_object_pass:attributes[{blank}]QueueTimeoutSaveOnShutd
|
|||
If set, all queue elements are saved to disk before [application]*rsyslog* terminates.
|
||||
|
||||
[[s1-configuring_rsyslog_on_a_logging_server]]
|
||||
==== Configuring rsyslog on a Logging Server
|
||||
== Configuring rsyslog on a Logging Server
|
||||
|
||||
The `rsyslog` service provides facilities both for running a logging server and for configuring individual systems to send their log files to the logging server. See xref:Viewing_and_Managing_Log_Files.adoc#ex-net_forwarding_with_queue[Reliable Forwarding of Log Messages to a Server] for information on client rsyslog configuration.
|
||||
|
||||
|
|
@ -1221,7 +1221,7 @@ Save the changes to the `/etc/rsyslog.conf` file.
|
|||
Your log server is now configured to receive and store log files from the other systems in your environment.
|
||||
|
||||
[[sec-Using_The_New_Template_Syntax_on_a_Logging_Server]]
|
||||
===== Using The New Template Syntax on a Logging Server
|
||||
=== Using The New Template Syntax on a Logging Server
|
||||
|
||||
Rsyslog 7 has a number of different templates styles. The string template most closely resembles the legacy format. Reproducing the templates from the example above using the string format would look as follows:
|
||||
|
||||
|
|
@ -1279,7 +1279,7 @@ input(type="imtcp" port="514" ruleset="remote1")
|
|||
----
|
||||
|
||||
[[s1-using_rsyslog_modules]]
|
||||
==== Using Rsyslog Modules
|
||||
== Using Rsyslog Modules
|
||||
indexterm:[rsyslog,modules]
|
||||
Due to its modular design, [application]*rsyslog* offers a variety of _modules_ which provide additional functionality. Note that modules can be written by third parties. Most modules provide additional inputs (see *Input Modules* below) or outputs (see *Output Modules* below). Other modules provide special functionality specific to each module. The modules may provide additional configuration directives that become available after a module is loaded. To load a module, use the following syntax:
|
||||
|
||||
|
|
@ -1323,7 +1323,7 @@ Note that when [application]*rsyslog* loads any modules, it provides them with a
|
|||
====
|
||||
|
||||
[[s2-importing_text_files]]
|
||||
===== Importing Text Files
|
||||
=== Importing Text Files
|
||||
|
||||
The Text File Input Module, abbreviated as [command]#imfile#, enables [application]*rsyslog* to convert any text file into a stream of syslog messages. You can use [command]#imfile# to import log messages from applications that create their own text file logs. To load [command]#imfile#, add the following into `/etc/rsyslog.conf`:
|
||||
|
||||
|
|
@ -1388,7 +1388,7 @@ $InputRunFileMonitor
|
|||
====
|
||||
|
||||
[[s2-exporting_messages_to_a_database]]
|
||||
===== Exporting Messages to a Database
|
||||
=== Exporting Messages to a Database
|
||||
|
||||
Processing of log data can be faster and more convenient when performed in a database rather than with text files. Based on the type of DBMS used, choose from various output modules such as [command]#ommysql#, [command]#ompgsql#, [command]#omoracle#, or [command]#ommongodb#. As an alternative, use the generic [command]#omlibdbi# output module that relies on the `libdbi` library. The [command]#omlibdbi# module supports database systems Firebird/Interbase, MS SQL, Sybase, SQLite, Ingres, Oracle, mSQL, MySQL, and PostgreSQL.
|
||||
|
||||
|
|
@ -1412,7 +1412,7 @@ First, the output module is loaded, then the communication port is specified. Ad
|
|||
====
|
||||
|
||||
[[s2-enabling_encrypted_transport]]
|
||||
===== Enabling Encrypted Transport
|
||||
=== Enabling Encrypted Transport
|
||||
|
||||
Confidentiality and integrity in network transmissions can be provided by either the *TLS* or *GSSAPI* encryption protocol.
|
||||
|
||||
|
|
@ -1421,12 +1421,12 @@ Confidentiality and integrity in network transmissions can be provided by either
|
|||
*Generic Security Service API* (GSSAPI) is an application programming interface for programs to access security services. To use it in connection with [application]*rsyslog* you must have a functioning [application]*Kerberos* environment.
|
||||
|
||||
[[s2-using_RELP]]
|
||||
===== Using RELP
|
||||
=== Using RELP
|
||||
|
||||
*Reliable Event Logging Protocol* (RELP) is a networking protocol for data logging in computer networks. It is designed to provide reliable delivery of event messages, which makes it useful in environments where message loss is not acceptable.
|
||||
|
||||
[[s1-interaction_of_rsyslog_and_journal]]
|
||||
==== Interaction of Rsyslog and Journal
|
||||
== Interaction of Rsyslog and Journal
|
||||
|
||||
As mentioned above, [application]*Rsyslog* and [application]*Journal*, the two logging applications present on your system, have several distinctive features that make them suitable for specific use cases. In many situations it is useful to combine their capabilities, for example to create structured messages and store them in a file database (see xref:Viewing_and_Managing_Log_Files.adoc#s1-structured_logging_with_rsyslog[Structured Logging with Rsyslog]). A communication interface needed for this cooperation is provided by input and output modules on the side of [application]*Rsyslog* and by the [application]*Journal*pass:attributes[{blank}]'s communication socket.
|
||||
|
||||
|
|
@ -1477,7 +1477,7 @@ $InputTCPServerRun 10514
|
|||
----
|
||||
|
||||
[[s1-structured_logging_with_rsyslog]]
|
||||
==== Structured Logging with Rsyslog
|
||||
== Structured Logging with Rsyslog
|
||||
|
||||
On systems that produce large amounts of log data, it can be convenient to maintain log messages in a *structured format*. With structured messages, it is easier to search for particular information, to produce statistics and to cope with changes and inconsistencies in message structure. [application]*Rsyslog* uses the *JSON* (JavaScript Object Notation) format to provide structure for log messages.
|
||||
|
||||
|
|
@ -1513,7 +1513,7 @@ The following is an example of a lumberjack-formatted message:
|
|||
To build this structure inside [application]*Rsyslog*, a template is used, see xref:Viewing_and_Managing_Log_Files.adoc#s2-filtering_structured_messages[Filtering Structured Messages]. Applications and servers can employ the `libumberlog` library to generate messages in the lumberjack-compliant form. For more information on `libumberlog`, see xref:Viewing_and_Managing_Log_Files.adoc#brid-Log_Files-Resources-Online[Online Documentation].
|
||||
|
||||
[[s2-importing_data_from_journal]]
|
||||
===== Importing Data from Journal
|
||||
=== Importing Data from Journal
|
||||
|
||||
The [command]#imjournal# module is [application]*Rsyslog*pass:attributes[{blank}]'s input module to natively read the journal files (see xref:Viewing_and_Managing_Log_Files.adoc#s1-interaction_of_rsyslog_and_journal[Interaction of Rsyslog and Journal]). Journal messages are then logged in text format as other rsyslog messages. However, with further processing, it is possible to translate meta data provided by [application]*Journal* into a structured message.
|
||||
|
||||
|
|
@ -1561,7 +1561,7 @@ $AddUnixListenSocket /run/systemd/journal/syslog
|
|||
You can translate all data and meta data stored by [application]*Journal* into structured messages. Some of these meta data entries are listed in xref:Viewing_and_Managing_Log_Files.adoc#ex-verbose_journalctl_output[Verbose journalctl Output], for a complete list of journal fields see the `systemd.journal-fields(7)` manual page. For example, it is possible to focus on *kernel journal fields*, that are used by messages originating in the kernel.
|
||||
|
||||
[[s2-filtering_structured_messages]]
|
||||
===== Filtering Structured Messages
|
||||
=== Filtering Structured Messages
|
||||
|
||||
To create a lumberjack-formatted message that is required by [application]*rsyslog*pass:attributes[{blank}]'s parsing module, use the following template:
|
||||
|
||||
|
|
@ -1582,7 +1582,7 @@ This template prepends the `@cee:` string to the JSON string and can be applied,
|
|||
----
|
||||
|
||||
[[s2-parsing_JSON]]
|
||||
===== Parsing JSON
|
||||
=== Parsing JSON
|
||||
|
||||
The `mmjsonparse` module is used for parsing structured messages.
|
||||
|
||||
|
|
@ -1601,7 +1601,7 @@ $ModLoad mmjsonparse
|
|||
In this example, the `mmjsonparse` module is loaded on the first line, then all messages are forwarded to it. Currently, there are no configuration parameters available for `mmjsonparse`.
|
||||
|
||||
[[s2-storing_messages_in_the_mongodb]]
|
||||
===== Storing Messages in the MongoDB
|
||||
=== Storing Messages in the MongoDB
|
||||
|
||||
[application]*Rsyslog* supports storing JSON logs in the MongoDB document database through the *ommongodb* output module.
|
||||
|
||||
|
|
@ -1625,7 +1625,7 @@ $ModLoad ommongodb
|
|||
You can shape the form of the final database output with use of templates. By default, [application]*rsyslog* uses a template based on standard [application]*lumberjack* field names.
|
||||
|
||||
[[s1-debugging_rsyslog]]
|
||||
==== Debugging Rsyslog
|
||||
== Debugging Rsyslog
|
||||
indexterm:[rsyslog,debugging]
|
||||
To run `rsyslogd` in debugging mode, use the following command:
|
||||
|
||||
|
|
@ -1656,7 +1656,7 @@ To check if syntax used in the `/etc/rsyslog.conf` file is valid use:
|
|||
Where `1` represents level of verbosity of the output message. This is a forward compatibility option because currently, only one level is provided. However, you must add this argument to run the validation.
|
||||
|
||||
[[sec-Troubleshooting_Logging_to_a_Server]]
|
||||
==== Troubleshooting Logging to a Server
|
||||
== Troubleshooting Logging to a Server
|
||||
|
||||
* Ensure the time is correctly set on the systems generating the log messages as well as on any logging servers. See xref:../basic-system-configuration/Configuring_the_Date_and_Time.adoc#ch-Configuring_the_Date_and_Time[Configuring the Date and Time] for information on checking and setting the time. See xref:../servers/Configuring_NTP_Using_ntpd.adoc#ch-Configuring_NTP_Using_ntpd[Configuring NTP Using ntpd] and xref:../servers/Configuring_NTP_Using_the_chrony_Suite.adoc#ch-Configuring_NTP_Using_the_chrony_Suite[Configuring NTP Using the chrony Suite] for information on using `NTP` to keep the system clock accurately set.
|
||||
|
||||
|
|
@ -1680,14 +1680,14 @@ For more information on opening and closing ports in `firewalld`, see the link:+
|
|||
See the `logger(1)` manual page for more information on the [command]#logger# command.
|
||||
|
||||
[[s1-Using_the_Journal]]
|
||||
==== Using the Journal
|
||||
== Using the Journal
|
||||
|
||||
The Journal is a component of [application]*systemd* that is responsible for viewing and management of log files. It can be used in parallel, or in place of a traditional syslog daemon, such as `rsyslogd`. The Journal was developed to address problems connected with traditional logging. It is closely integrated with the rest of the system, supports various logging technologies and access management for the log files.
|
||||
|
||||
Logging data is collected, stored, and processed by the Journal's `journald` service. It creates and maintains binary files called *journals* based on logging information that is received from the kernel, from user processes, from standard output, and standard error output of system services or via its native API. These journals are structured and indexed, which provides relatively fast seek times. Journal entries can carry a unique identifier. The `journald` service collects numerous meta data fields for each log message. The actual journal files are secured, and therefore cannot be manually edited.
|
||||
|
||||
[[s2-Viewing_Log_Files]]
|
||||
===== Viewing Log Files
|
||||
=== Viewing Log Files
|
||||
|
||||
To access the journal logs, use the [application]*journalctl* tool. For a basic view of the logs type as `root`:
|
||||
|
||||
|
|
@ -1785,7 +1785,7 @@ This example lists fields that identify a single log entry. These meta data can
|
|||
====
|
||||
|
||||
[[s2-Access_Control]]
|
||||
===== Access Control
|
||||
=== Access Control
|
||||
|
||||
By default, [application]*Journal* users without `root` privileges can only see log files generated by them. The system administrator can add selected users to the *adm* group, which grants them access to complete log files. To do so, type as `root`:
|
||||
|
||||
|
|
@ -1797,7 +1797,7 @@ By default, [application]*Journal* users without `root` privileges can only see
|
|||
Here, replace _username_ with a name of the user to be added to the *adm* group. This user then receives the same output of the [command]#journalctl# command as the root user. Note that access control only works when persistent storage is enabled for [application]*Journal*.
|
||||
|
||||
[[s2-Using_The_Live_View]]
|
||||
===== Using The Live View
|
||||
=== Using The Live View
|
||||
|
||||
When called without parameters, [command]#journalctl# shows the full list of entries, starting with the oldest entry collected. With the live view, you can supervise the log messages in real time as new entries are continuously printed as they appear. To start [application]*journalctl* in live view mode, type:
|
||||
|
||||
|
|
@ -1809,7 +1809,7 @@ When called without parameters, [command]#journalctl# shows the full list of ent
|
|||
This command returns a list of the ten most current log lines. The [application]*journalctl* utility then stays running and waits for new changes to show them immediately.
|
||||
|
||||
[[s2-Filtering_Messages]]
|
||||
===== Filtering Messages
|
||||
=== Filtering Messages
|
||||
|
||||
The output of the [command]#journalctl# command executed without parameters is often extensive, therefore you can use various filtering methods to extract information to meet your needs.
|
||||
|
||||
|
|
@ -1960,7 +1960,7 @@ You can apply the aforementioned filtering also in the live-view mode to keep tr
|
|||
----
|
||||
|
||||
[[s2-Enabling_Persistent_Storage]]
|
||||
===== Enabling Persistent Storage
|
||||
=== Enabling Persistent Storage
|
||||
|
||||
By default, [application]*Journal* stores log files only in memory or a small ring-buffer in the `/run/log/journal/` directory. This is sufficient to show recent log history with [command]#journalctl#. This directory is volatile, log data is not saved permanently. With the default configuration, syslog reads the journal logs and stores them in the `/var/log/` directory. With persistent logging enabled, journal files are stored in `/var/log/journal` which means they persist after reboot. Journal can then replace [application]*rsyslog* for some users (but see the chapter introduction).
|
||||
|
||||
|
|
@ -1993,12 +1993,12 @@ Then, restart `journald` to apply the change:
|
|||
----
|
||||
|
||||
[[s1-managing_log_files_in_a_graphical_environment]]
|
||||
==== Managing Log Files in a Graphical Environment
|
||||
== Managing Log Files in a Graphical Environment
|
||||
|
||||
As an alternative to the aforementioned command-line utilities, Red{nbsp}Hat Enterprise{nbsp}Linux{nbsp}7 provides an accessible GUI for managing log messages.
|
||||
|
||||
[[s2-logfiles-viewing]]
|
||||
===== Viewing Log Files
|
||||
=== Viewing Log Files
|
||||
indexterm:[log files,viewing]
|
||||
Most log files are stored in plain text format. You can view them with any text editor such as [command]#Vi# or [application]*Emacs*. Some log files are readable by all users on the system; however, root privileges are required to read most log files.
|
||||
indexterm:[gnome-system-log,System Log]
|
||||
|
|
@ -2072,7 +2072,7 @@ image::redhat-filter-enable.png[System Log - Enabling a Filter]
|
|||
When you select the `Show matches only` option, only the matched strings will be shown in the log file you are currently viewing.
|
||||
|
||||
[[s2-logfiles-adding]]
|
||||
===== Adding a Log File
|
||||
=== Adding a Log File
|
||||
|
||||
To add a log file you want to view in the list, select menu:File[
|
||||
> `Open` >
|
||||
|
|
@ -2094,7 +2094,7 @@ The [application]*System Log* also allows you to open log files zipped in the `.
|
|||
====
|
||||
|
||||
[[s2-logfiles-examining]]
|
||||
===== Monitoring Log Files
|
||||
=== Monitoring Log Files
|
||||
indexterm:[log files,monitoring]indexterm:[System Log,monitoring]
|
||||
[application]*System Log* monitors all opened logs by default. If a new line is added to a monitored log file, the log name appears in bold in the log list. If the log file is selected or displayed, the new lines appear in bold at the bottom of the log file. xref:Viewing_and_Managing_Log_Files.adoc#fig-redhat-logviewer-monitoring[System Log - new log alert] illustrates a new alert in the `cron` log file and in the `messages` log file. Clicking on the `messages` log file displays the logs in the file with the new lines in bold.
|
||||
|
||||
|
|
@ -2104,7 +2104,7 @@ indexterm:[log files,monitoring]indexterm:[System Log,monitoring]
|
|||
image::redhat-logviewer-monitoring.png[System Log - New Log Alert]
|
||||
|
||||
[[s1-log-files-additional-resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
|
||||
For more information on how to configure the `rsyslog` daemon and how to locate, view, and monitor log files, see the resources listed below.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
== Monitoring and Automation
|
||||
= Monitoring and Automation
|
||||
|
||||
This part describes various tools that allow system administrators to monitor system performance, automate system tasks, and report bugs.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-DNF]]
|
||||
=== DNF
|
||||
= DNF
|
||||
|
||||
[application]*DNF* is the {OSORG} package manager that is able to query for information about packages, fetch packages from repositories, install and uninstall packages using automatic dependency resolution, and update an entire system to the latest available packages. DNF performs automatic dependency resolution on packages you are updating, installing or removing, and thus is able to automatically determine, fetch and install all available dependent packages. DNF can be configured with new, additional repositories, or _package sources_, and also provides many plug-ins which enhance and extend its capabilities. DNF is able to perform many of the same tasks that [application]*RPM* can; additionally, many of the command line options are similar. DNF enables easy and simple package management on a single machine or on groups of them.
|
||||
|
||||
|
|
@ -30,10 +30,10 @@ You must have superuser privileges in order to use the [command]#dnf# command to
|
|||
====
|
||||
|
||||
[[sec-Checking_For_and_Updating_Packages]]
|
||||
==== Checking For and Updating Packages
|
||||
== Checking For and Updating Packages
|
||||
|
||||
[[sec-Checking_For_Updates]]
|
||||
===== Checking For Updates
|
||||
=== Checking For Updates
|
||||
indexterm:[DNF Updates,checking for updates]
|
||||
The quickest way to check for updates is to attempt to install any available updates by using the [command]#dnf upgrade# command as follows:
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ The packages in the above output are listed as having updated versions. The line
|
|||
* `updates-testing` — the repository in which the updated package is located.
|
||||
|
||||
[[sec-Updating_Packages]]
|
||||
===== Updating Packages
|
||||
=== Updating Packages
|
||||
indexterm:[DNF Updates,updating packages]
|
||||
You can choose to update a single package, multiple packages, or all packages at once. If any dependencies of the package, or packages, you update have updates available themselves, then they are updated too.
|
||||
|
||||
|
|
@ -137,16 +137,16 @@ To update all packages and their dependencies, enter [command]#dnf upgrade# with
|
|||
----
|
||||
|
||||
[[sec-Preserving_Configuration_File_Changes]]
|
||||
===== Preserving Configuration File Changes
|
||||
=== Preserving Configuration File Changes
|
||||
indexterm:[Configuration File Changes]
|
||||
You will inevitably make changes to the configuration files installed by packages as you use your {MAJOROS} system. [application]*RPM*, which DNF uses to perform changes to the system, provides a mechanism for ensuring their integrity. See xref:../RPM.adoc#sec-Installing_and_Upgrading[Installing and Upgrading Packages] for details on how to manage changes to configuration files across package upgrades.
|
||||
|
||||
[[sec-Packages_and_Package_Groups]]
|
||||
==== Packages and Package Groups
|
||||
== Packages and Package Groups
|
||||
indexterm:[packages,packages and package groups]indexterm:[DNF,packages and package groups]
|
||||
|
||||
[[sec-Searching_Packages]]
|
||||
===== Searching Packages
|
||||
=== Searching Packages
|
||||
indexterm:[packages,searching packages with DNF,dnf search]indexterm:[DNF,searching packages with DNF,dnf search]
|
||||
You can search all *RPM* package names and summaries by using the following command:
|
||||
|
||||
|
|
@ -167,11 +167,11 @@ This command displays the list of matches for each term. For example, to list al
|
|||
----
|
||||
~]# dnf search meld kompare
|
||||
Loaded plugins: langpacks, presto, refresh-packagekit
|
||||
============================== N/S Matched: meld ===============================
|
||||
============================ N/S Matched: meld ===============================
|
||||
meld.noarch : Visual diff and merge tool
|
||||
python-meld3.x86_64 : HTML/XML templating system for Python
|
||||
|
||||
============================= N/S Matched: kompare =============================
|
||||
=========================== N/S Matched: kompare =============================
|
||||
komparator.x86_64 : Kompare and merge two folders
|
||||
|
||||
Name and summary matches only, use "search all" for everything.
|
||||
|
|
@ -179,7 +179,7 @@ komparator.x86_64 : Kompare and merge two folders
|
|||
indexterm:[packages,searching for packages with DNF,dnf search]indexterm:[DNF,searching for packages with DNF,dnf search]
|
||||
|
||||
[[sec-Listing_Packages]]
|
||||
===== Listing Packages
|
||||
=== Listing Packages
|
||||
indexterm:[packages,listing packages with DNF,dnf search]indexterm:[DNF,listing packages with DNF,dnf list]
|
||||
[command]#dnf list# and related commands provide information about packages, package groups, and repositories.
|
||||
|
||||
|
|
@ -360,7 +360,7 @@ The default action is to list all packages available and installed from the repo
|
|||
====
|
||||
|
||||
[[sec-Displaying_Package_Information]]
|
||||
===== Displaying Package Information
|
||||
=== Displaying Package Information
|
||||
indexterm:[packages,displaying packages with DNF,dnf info]indexterm:[DNF,displaying packages with DNF,dnf info]
|
||||
To display information about one or more packages, use a command as follows:
|
||||
|
||||
|
|
@ -432,7 +432,7 @@ _output truncated_
|
|||
----
|
||||
|
||||
[[sec-Installing]]
|
||||
===== Installing Packages
|
||||
=== Installing Packages
|
||||
indexterm:[packages,installing with DNF]indexterm:[DNF,installing with DNF]
|
||||
DNF allows you to install both a single package and multiple packages, as well as a package group of your choice.
|
||||
|
||||
|
|
@ -541,7 +541,7 @@ For example, the following are alternative but equivalent ways of installing the
|
|||
----
|
||||
|
||||
[[sec-Removing]]
|
||||
===== Removing Packages
|
||||
=== Removing Packages
|
||||
indexterm:[packages,uninstalling packages with DNF]indexterm:[DNF,uninstalling packages with DNF]
|
||||
Similarly to package installation, DNF allows you to uninstall (remove in [application]*RPM* and DNF terminology) both individual packages and a package group.
|
||||
|
||||
|
|
@ -600,7 +600,7 @@ The following are alternative but equivalent ways of removing the `KDE Plasma Wo
|
|||
----
|
||||
|
||||
[[sec-DNF-Transaction_History]]
|
||||
===== Working with Transaction History
|
||||
=== Working with Transaction History
|
||||
|
||||
The [command]#dnf history# command allows users to review information about a timeline of DNF transactions, the dates and times on when they occurred, the number of packages affected, whether transactions succeeded or were aborted, and if the RPM database was changed between transactions. Additionally, this command can be used to undo or redo certain transactions.
|
||||
|
||||
|
|
@ -685,7 +685,7 @@ Both commands also accept the `last` keyword to undo or repeat the latest transa
|
|||
Note that both [command]#dnf history undo# and [command]#dnf history redo# commands merely revert or repeat the steps that were performed during a transaction, and will fail if the required packages are not available. For example, if the transaction installed a new package, the [command]#dnf history undo# command will uninstall it and also attempt to downgrade all updated packages to their previous version, but the command will fail if the required packages are not available.
|
||||
|
||||
[[sec-Configuring_DNF_and_DNF_Repositories]]
|
||||
==== Configuring DNF and DNF Repositories
|
||||
== Configuring DNF and DNF Repositories
|
||||
indexterm:[DNF,configuring DNF and DNF repositories]indexterm:[DNF,DNF repositories,configuring DNF and DNF repositories]
|
||||
The configuration file for DNF and related utilities is located at `/etc/dnf/dnf.conf`. This file contains one mandatory `[main]` section, which allows you to set DNF options that have global effect, and may also contain one or more `[pass:attributes[{blank}]_repository_pass:attributes[{blank}]]` sections, which allow you to set repository-specific options. However, it is recommended to define individual repositories in new or existing `.repo` files in the `/etc/yum.repos.d/` directory. The values you define in individual `[pass:attributes[{blank}]_repository_pass:attributes[{blank}]]` sections of the `/etc/dnf/dnf.conf` file override values set in the `[main]` section.
|
||||
|
||||
|
|
@ -702,7 +702,7 @@ This section shows you how to:
|
|||
* set up your own custom DNF repository.
|
||||
|
||||
[[sec-Setting_main_Options]]
|
||||
===== Setting [main] Options
|
||||
=== Setting [main] Options
|
||||
indexterm:[DNF,setting [main] options]
|
||||
The `/etc/dnf/dnf.conf` configuration file contains exactly one `[main]` section, and while some of the key-value pairs in this section affect how [command]#dnf# operates, others affect how DNF treats repositories.
|
||||
|
||||
|
|
@ -759,7 +759,7 @@ The defaults for the [option]`installonlypkgs` directive include several differe
|
|||
For a complete list of available `[main]` options, refer to the `[MAIN] OPTIONS` section of the *dnf.conf*(5) manual page.
|
||||
|
||||
[[sec-Setting_repository_Options]]
|
||||
===== Setting [repository] Options
|
||||
=== Setting [repository] Options
|
||||
indexterm:[DNF,setting [repository] options]
|
||||
The `[pass:attributes[{blank}]_repository_pass:attributes[{blank}]]` sections, where _repository_ is a unique repository ID such as `my_personal_repo` (spaces are not permitted), allow you to define individual DNF repositories.
|
||||
|
||||
|
|
@ -816,7 +816,7 @@ Turning repositories on and off can also be performed by passing either the [opt
|
|||
Many more `[pass:attributes[{blank}]_repository_pass:attributes[{blank}]]` options exist. For a complete list, refer to the `[repository] OPTIONS` section of the *dnf.conf*(5) manual page.
|
||||
|
||||
[[sec-Using_DNF_Variables]]
|
||||
===== Using DNF Variables
|
||||
=== Using DNF Variables
|
||||
indexterm:[DNF,variables]
|
||||
Variables can be used only in the appropriate sections of the DNF configuration files, namely the `/etc/dnf/dnf.conf` file and all `.repo` files in the `/etc/yum.repos.d/` directory. Repository variables include:
|
||||
|
||||
|
|
@ -827,14 +827,14 @@ Variables can be used only in the appropriate sections of the DNF configuration
|
|||
`$basearch`:: Refers to the base architecture of the system. For example, i686 and i586 machines both have a base architecture of `i386`, and AMD64 and Intel64 machines have a base architecture of `x86_64`.
|
||||
|
||||
[[sec-Viewing_the_Current_Configuration]]
|
||||
==== Viewing the Current Configuration
|
||||
== Viewing the Current Configuration
|
||||
|
||||
To list all configuration options and their corresponding values, and the repositories, execute the [command]#dnf config-manager# command with the [option]`--dump` option:
|
||||
|
||||
[subs="attributes"]
|
||||
----
|
||||
~]${nbsp}dnf config-manager --dump
|
||||
=============================== main ======================================
|
||||
============================= main ======================================
|
||||
[main]
|
||||
alwaysprompt = True
|
||||
assumeno = False
|
||||
|
|
@ -847,7 +847,7 @@ cachedir = /var/cache/dnf/x86_64/22
|
|||
----
|
||||
|
||||
[[sec-Managing_DNF_Repositories]]
|
||||
==== Adding, Enabling, and Disabling a DNF Repository
|
||||
== Adding, Enabling, and Disabling a DNF Repository
|
||||
indexterm:[DNF,repository]
|
||||
xref:DNF.adoc#sec-Setting_repository_Options[Setting [repository] Options] describes various options you can use to define a DNF repository. This section explains how to add, enable, and disable a repository by using the [command]#dnf config-manager# command.
|
||||
|
||||
|
|
@ -898,7 +898,7 @@ To disable a DNF repository, run the following command as `root`:
|
|||
…where _repository_ is the unique repository ID. To display the current configuration, add the [option]`--dump` option.
|
||||
|
||||
[[sec-Additional_Resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
indexterm:[DNF,Additional Resources]
|
||||
.Installed Documentation
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
== Package Management
|
||||
= Package Management
|
||||
|
||||
All software on a {MAJOROS} system is divided into RPM packages, which can be installed, upgraded, or removed. This part describes how to manage packages on {MAJOROS} using [application]*DNF*.
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-Configuring_NTP_Using_ntpd]]
|
||||
=== Configuring NTP Using ntpd
|
||||
= Configuring NTP Using ntpd
|
||||
|
||||
[[s1-Introduction_to_NTP]]
|
||||
==== Introduction to NTP
|
||||
== Introduction to NTP
|
||||
|
||||
The _Network Time Protocol_ (*NTP*) enables the accurate dissemination of time and date information in order to keep the time clocks on networked computer systems synchronized to a common reference over the network or the Internet. Many standards bodies around the world have atomic clocks which may be made available as a reference. The satellites that make up the Global Position System contain more than one atomic clock, making their time signals potentially very accurate. Their signals can be deliberately degraded for military reasons. An ideal situation would be where each site has a server, with its own reference clock attached, to act as a site-wide time server. Many devices which obtain the time and date via low frequency radio transmissions or the Global Position System (GPS) exist. However for most situations, a range of publicly accessible time servers connected to the Internet at geographically dispersed locations can be used. These `NTP` servers provide "pass:attributes[{blank}]_Coordinated Universal Time_pass:attributes[{blank}]" (*UTC*). Information about these time servers can found at [citetitle]_www.pool.ntp.org_.
|
||||
|
||||
|
|
@ -15,7 +15,7 @@ Accurate time keeping is important for a number of reasons in IT. In networking
|
|||
The user space daemon updates the system clock, which is a software clock running in the kernel. Linux uses a software clock as its system clock for better resolution than the typical embedded hardware clock referred to as the "pass:attributes[{blank}]_Real Time Clock_pass:attributes[{blank}]" *(RTC)*. See the `rtc(4)` and `hwclock(8)` man pages for information on hardware clocks. The system clock can keep time by using various clock sources. Usually, the _Time Stamp Counter_ (*TSC*) is used. The TSC is a CPU register which counts the number of cycles since it was last reset. It is very fast, has a high resolution, and there are no interrupts. On system start, the system clock reads the time and date from the RTC. The time kept by the RTC will drift away from actual time by up to 5 minutes per month due to temperature variations. Hence the need for the system clock to be constantly synchronized with external time references. When the system clock is being synchronized by `ntpd`, the kernel will in turn update the RTC every 11 minutes automatically.
|
||||
|
||||
[[s1-NTP_Strata]]
|
||||
==== NTP Strata
|
||||
== NTP Strata
|
||||
|
||||
`NTP` servers are classified according to their synchronization distance from the atomic clocks which are the source of the time signals. The servers are thought of as being arranged in layers, or strata, from 1 at the top down to 15. Hence the word stratum is used when referring to a specific layer. Atomic clocks are referred to as Stratum 0 as this is the source, but no Stratum 0 packet is sent on the Internet, all stratum 0 atomic clocks are attached to a server which is referred to as stratum 1. These servers send out packets marked as Stratum 1. A server which is synchronized by means of packets marked stratum `n` belongs to the next, lower, stratum and will mark its packets as stratum `n+1`. Servers of the same stratum can exchange packets with each other but are still designated as belonging to just the one stratum, the stratum one below the best reference they are synchronized to. The designation Stratum 16 is used to indicate that the server is not currently synchronized to a reliable time source.
|
||||
|
||||
|
|
@ -47,7 +47,7 @@ Stratum 15::: Reads from stratum 14; This is the lowest stratum.
|
|||
This process continues down to Stratum 15 which is the lowest valid stratum. The label Stratum 16 is used to indicated an unsynchronized state.
|
||||
|
||||
[[s1-Understanding_NTP]]
|
||||
==== Understanding NTP
|
||||
== Understanding NTP
|
||||
|
||||
The version of `NTP` used by {MAJOROS} is as described in [citetitle]_link:++http://www.rfc-editor.org/info/rfc1305++[RFC 1305 Network Time Protocol (Version 3)
|
||||
Specification, Implementation and Analysis]_ and [citetitle]_link:++http://www.rfc-editor.org/info/rfc5905++[RFC 5905 Network Time Protocol Version 4: Protocol and Algorithms Specification]_
|
||||
|
|
@ -63,19 +63,19 @@ When a packet containing time information is received it is not immediately resp
|
|||
Some software may fail or produce an error if the time is changed backwards. For systems that are sensitive to step changes in the time, the threshold can be changed to 600s instead of 128ms using the [option]`-x` option (unrelated to the [option]`-g` option). Using the [option]`-x` option to increase the stepping limit from 0.128s to 600s has a drawback because a different method of controlling the clock has to be used. It disables the kernel clock discipline and may have a negative impact on the clock accuracy. The [option]`-x` option can be added to the `/etc/sysconfig/ntpd` configuration file.
|
||||
|
||||
[[s1-Understanding_the_Drift_File]]
|
||||
==== Understanding the Drift File
|
||||
== Understanding the Drift File
|
||||
|
||||
The drift file is used to store the frequency offset between the system clock running at its nominal frequency and the frequency required to remain in synchronization with UTC. If present, the value contained in the drift file is read at system start and used to correct the clock source. Use of the drift file reduces the time required to achieve a stable and accurate time. The value is calculated, and the drift file replaced, once per hour by `ntpd`. The drift file is replaced, rather than just updated, and for this reason the drift file must be in a directory for which the `ntpd` has write permissions.
|
||||
|
||||
[[s1-UTC_timezones_and_DST]]
|
||||
==== UTC, Timezones, and DST
|
||||
== UTC, Timezones, and DST
|
||||
|
||||
As `NTP` is entirely in UTC (Universal Time, Coordinated), Timezones and DST (Daylight Saving Time) are applied locally by the system. The file `/etc/localtime` is a copy of, or symlink to, a zone information file from `/usr/share/zoneinfo`. The RTC may be in localtime or in UTC, as specified by the 3rd line of `/etc/adjtime`, which will be one of LOCAL or UTC to indicate how the RTC clock has been set. Users can easily change this setting using the checkbox `System Clock Uses UTC` in the [application]*Date and Time* graphical configuration tool. See xref:../basic-system-configuration/Configuring_the_Date_and_Time.adoc#ch-Configuring_the_Date_and_Time[Configuring the Date and Time] for information on how to use that tool. Running the RTC in UTC is recommended to avoid various problems when daylight saving time is changed.
|
||||
|
||||
The operation of `ntpd` is explained in more detail in the man page `ntpd(8)`. The resources section lists useful sources of information. See xref:Configuring_NTP_Using_ntpd.adoc#s1-ntpd_additional-resources[Additional Resources].
|
||||
|
||||
[[s1-Authentication_Options_for_NTP]]
|
||||
==== Authentication Options for NTP
|
||||
== Authentication Options for NTP
|
||||
|
||||
`NTPv4` added support for the Autokey Security Architecture, which is based on public asymmetric cryptography while retaining support for symmetric key cryptography. The Autokey Security Architecture is described in [citetitle]_link:++http://www.rfc-editor.org/info/rfc5906++[RFC 5906 Network Time Protocol Version 4: Autokey Specification]_. The man page `ntp_auth(5)` describes the authentication options and commands for `ntpd`.
|
||||
|
||||
|
|
@ -84,17 +84,17 @@ An attacker on the network can attempt to disrupt a service by sending `NTP` pac
|
|||
The broadcast and multicast modes require authentication by default. If you have decided to trust the network then you can disable authentication by using [command]#disable auth# directive in the `ntp.conf` file. Alternatively, authentication needs to be configured by using SHA1 or MD5 symmetric keys, or by public (asymmetric) key cryptography using the Autokey scheme. The Autokey scheme for asymmetric cryptography is explained in the `ntp_auth(8)` man page and the generation of keys is explained in `ntp-keygen(8`). To implement symmetric key cryptography, see xref:Configuring_NTP_Using_ntpd.adoc#s2_Configuring_Symmetric_Authentication_Using_a_Key[Configuring Symmetric Authentication Using a Key] for an explanation of the [option]`key` option.
|
||||
|
||||
[[s1-Managing_the_Time_on_Virtual_Machines]]
|
||||
==== Managing the Time on Virtual Machines
|
||||
== Managing the Time on Virtual Machines
|
||||
|
||||
Virtual machines cannot access a real hardware clock and a virtual clock is not stable enough as the stability is dependent on the host systems work load. For this reason, para-virtualized clocks should be provided by the virtualization application in use (for more information see _https://docs.fedoraproject.org/en-US/Fedora/18/html/Virtualization_Administration_Guide/sect-Virtualization-Tips_and_tricks-Libvirt_Managed_Timers.html[Libvirt Managed Timers]_ in the _Virtualization Administration Guide_). On {MAJOROS} with [application]*KVM* the default clock source is [option]`kvm-clock`. See the [citetitle]_link:++https://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/chap-Virtualization-KVM_guest_timing_management.html++[KVM guest timing management]_ chapter of the [citetitle]_Virtualization Host Configuration and Guest Installation Guide_.
|
||||
|
||||
[[s1-Understanding_Leap_Seconds]]
|
||||
==== Understanding Leap Seconds
|
||||
== Understanding Leap Seconds
|
||||
|
||||
Greenwich Mean Time (GMT) was derived by measuring the solar day, which is dependent on the Earth's rotation. When atomic clocks were first made, the potential for more accurate definitions of time became possible. In 1958, International Atomic Time (TAI) was introduced based on the more accurate and very stable atomic clocks. A more accurate astronomical time, Universal Time 1 (UT1), was also introduced to replace GMT. The atomic clocks are in fact far more stable than the rotation of the Earth and so the two times began to drift apart. For this reason UTC was introduced as a practical measure. It is kept within one second of UT1 but to avoid making many small trivial adjustments it was decided to introduce the concept of a _leap second_ in order to reconcile the difference in a manageable way. The difference between UT1 and UTC is monitored until they drift apart by more than half a second. Then only is it deemed necessary to introduce a one second adjustment, forward or backward. Due to the erratic nature of the Earth's rotational speed, the need for an adjustment cannot be predicted far into the future. The decision as to when to make an adjustment is made by the [citetitle]_link:++http://www.iers.org++[International Earth Rotation and Reference Systems Service (IERS)]_. However, these announcements are important only to administrators of Stratum 1 servers because `NTP` transmits information about pending leap seconds and applies them automatically.
|
||||
|
||||
[[s1-Understanding_the_ntpd_Configuration_File]]
|
||||
==== Understanding the ntpd Configuration File
|
||||
== Understanding the ntpd Configuration File
|
||||
|
||||
The daemon, `ntpd`, reads the configuration file at system start or when the service is restarted. The default location for the file is `/etc/ntp.conf` and you can view the file by entering the following command:
|
||||
|
||||
|
|
@ -191,7 +191,7 @@ When the `DHCP` client program, [application]*dhclient*, receives a list of `NTP
|
|||
====
|
||||
|
||||
[[s1-Understanding_the_ntpd_Sysconfig_File]]
|
||||
==== Understanding the ntpd Sysconfig File
|
||||
== Understanding the ntpd Sysconfig File
|
||||
|
||||
The file will be read by the `ntpd` init script on service start. The default contents is as follows:
|
||||
|
||||
|
|
@ -203,7 +203,7 @@ OPTIONS="-g"
|
|||
The [option]`-g` option enables `ntpd` to ignore the offset limit of 1000s and attempt to synchronize the time even if the offset is larger than 1000s, but only on system start. Without that option [application]*ntpd* will exit if the time offset is greater than 1000s. It will also exit after system start if the service is restarted and the offset is greater than 1000s even with the [option]`-g` option.
|
||||
|
||||
[[s1-Disabling_chrony]]
|
||||
==== Disabling chrony
|
||||
== Disabling chrony
|
||||
|
||||
In order to use `ntpd` the default user space daemon, `chronyd`, must be stopped and disabled. Issue the following command as `root`:
|
||||
|
||||
|
|
@ -227,7 +227,7 @@ To check the status of `chronyd`, issue the following command:
|
|||
----
|
||||
|
||||
[[s1-Checking_if_the_NTP_Daemon_is_Installed]]
|
||||
==== Checking if the NTP Daemon is Installed
|
||||
== Checking if the NTP Daemon is Installed
|
||||
|
||||
To check if `ntpd` is installed, enter the following command as `root`:
|
||||
|
||||
|
|
@ -239,7 +239,7 @@ To check if `ntpd` is installed, enter the following command as `root`:
|
|||
`NTP` is implemented by means of the daemon or service `ntpd`, which is contained within the [package]*ntp* package.
|
||||
|
||||
[[s1-Installing_the_NTP_Daemon_ntpd]]
|
||||
==== Installing the NTP Daemon (ntpd)
|
||||
== Installing the NTP Daemon (ntpd)
|
||||
|
||||
To install `ntpd`, enter the following command as `root`:
|
||||
|
||||
|
|
@ -256,7 +256,7 @@ To enable `ntpd` at system start, enter the following command as `root`:
|
|||
----
|
||||
|
||||
[[s1-Checking_the_status_of_NTP]]
|
||||
==== Checking the Status of NTP
|
||||
== Checking the Status of NTP
|
||||
|
||||
To check if `ntpd` is running and configured to run at system start, issue the following command:
|
||||
|
||||
|
|
@ -284,7 +284,7 @@ synchronised to NTP server (10.5.26.10) at stratum 2
|
|||
----
|
||||
|
||||
[[s1-Configure_the_Firewall_to_Allow_Incoming_NTP_Packets]]
|
||||
==== Configure the Firewall to Allow Incoming NTP Packets
|
||||
== Configure the Firewall to Allow Incoming NTP Packets
|
||||
|
||||
The `NTP` traffic consists of `UDP` packets on port `123` and needs to be permitted through network and host-based firewalls in order for `NTP` to function.
|
||||
|
||||
|
|
@ -304,7 +304,7 @@ The `Firewall Configuration` window opens. Note, this command can be run as norm
|
|||
Look for the word "Connected" in the lower left corner. This indicates that the [application]*firewall-config* tool is connected to the user space daemon, `firewalld`.
|
||||
|
||||
[[s2-Change_the_firewall_settings]]
|
||||
===== Change the Firewall Settings
|
||||
=== Change the Firewall Settings
|
||||
|
||||
To immediately change the current firewall settings, ensure the drop-down selection menu labeled `Configuration` is set to `Runtime`. Alternatively, to edit the settings to be applied at the next system start, or firewall reload, select `Permanent` from the drop-down list.
|
||||
|
||||
|
|
@ -318,14 +318,14 @@ When making changes to the firewall settings in `Permanent` mode, your selection
|
|||
====
|
||||
|
||||
[[s2-Open_Ports_in_the_firewall_for_ntp_packets]]
|
||||
===== Open Ports in the Firewall for NTP Packets
|
||||
=== Open Ports in the Firewall for NTP Packets
|
||||
|
||||
To permit traffic through the firewall to a certain port, start the [application]*firewall-config* tool and select the network zone whose settings you want to change. Select the `Ports` tab and then click the btn:[Add] button. The `Port and Protocol` window opens.
|
||||
|
||||
Enter the port number `123` and select `udp` from the drop-down list.
|
||||
|
||||
[[s1-Configure_ntpdate_Servers]]
|
||||
==== Configure ntpdate Servers
|
||||
== Configure ntpdate Servers
|
||||
|
||||
The purpose of the `ntpdate` service is to set the clock during system boot. This was used previously to ensure that the services started after `ntpdate` would have the correct time and not observe a jump in the clock. The use of `ntpdate` and the list of step-tickers is considered deprecated and so Fedora uses the [option]`-g` option to the [command]#ntpd# command and not `ntpdate` by default.
|
||||
|
||||
|
|
@ -348,12 +348,12 @@ To enable the service to run at system start, issue the following command as `ro
|
|||
In Fedora the default `/etc/ntp/step-tickers` file contains `0.fedora.pool.ntp.org`. To configure additional `ntpdate` servers, using a text editor running as `root`, edit `/etc/ntp/step-tickers`. The number of servers listed is not very important as `ntpdate` will only use this to obtain the date information once when the system is starting. If you have an internal time server then use that host name for the first line. An additional host on the second line as a backup is sensible. The selection of backup servers and whether the second host is internal or external depends on your risk assessment. For example, what is the chance of any problem affecting the first server also affecting the second server? Would connectivity to an external server be more likely to be available than connectivity to internal servers in the event of a network failure disrupting access to the first server?
|
||||
|
||||
[[s1-Configure_NTP]]
|
||||
==== Configure NTP
|
||||
== Configure NTP
|
||||
|
||||
To change the default configuration of the `NTP` service, use a text editor running as `root` user to edit the `/etc/ntp.conf` file. This file is installed together with `ntpd` and is configured to use time servers from the Fedora pool by default. The man page `ntp.conf(5)` describes the command options that can be used in the configuration file apart from the access and rate limiting commands which are explained in the `ntp_acc(5)` man page.
|
||||
|
||||
[[s2-Configure_Access_Control_to_an_NTP_service]]
|
||||
===== Configure Access Control to an NTP Service
|
||||
=== Configure Access Control to an NTP Service
|
||||
|
||||
To restrict or control access to the `NTP` service running on a system, make use of the [command]#restrict# command in the `ntp.conf` file. See the commented out example:
|
||||
|
||||
|
|
@ -401,7 +401,7 @@ To configure rate limit access to not respond at all to a query, the respective
|
|||
The `ntpq` and `ntpdc` queries can be used in amplification attacks (see [citetitle]_link:++https://access.redhat.com/security/cve/CVE-2013-5211++[CVE-2013-5211]_ for more details), do not remove the [option]`noquery` option from the [command]#restrict default# command on publicly accessible systems.
|
||||
|
||||
[[s2_Configure_Rate_Limiting_Access_to_an_NTP_Service]]
|
||||
===== Configure Rate Limiting Access to an NTP Service
|
||||
=== Configure Rate Limiting Access to an NTP Service
|
||||
|
||||
To enable rate limiting access to the `NTP` service running on a system, add the [option]`limited` option to the [command]#restrict# command as explained in xref:Configuring_NTP_Using_ntpd.adoc#s2-Configure_Access_Control_to_an_NTP_service[Configure Access Control to an NTP Service]. If you do not want to use the default discard parameters, then also use the [command]#discard# command as explained here.
|
||||
|
||||
|
|
@ -431,7 +431,7 @@ discard average 4 minimum 2
|
|||
----
|
||||
|
||||
[[s2_Adding_a_Peer_Address]]
|
||||
===== Adding a Peer Address
|
||||
=== Adding a Peer Address
|
||||
|
||||
To add the address of a peer, that is to say, the address of a server running an `NTP` service of the same stratum, make use of the [command]#peer# command in the `ntp.conf` file.
|
||||
|
||||
|
|
@ -445,7 +445,7 @@ The [command]#peer# command takes the following form:
|
|||
where _address_ is an `IP` unicast address or a `DNS` resolvable name. The address must only be that of a system known to be a member of the same stratum. Peers should have at least one time source that is different to each other. Peers are normally systems under the same administrative control.
|
||||
|
||||
[[s2_Adding_a_Server_Address]]
|
||||
===== Adding a Server Address
|
||||
=== Adding a Server Address
|
||||
|
||||
To add the address of a server, that is to say, the address of a server running an `NTP` service of a higher stratum, make use of the [command]#server# command in the `ntp.conf` file.
|
||||
|
||||
|
|
@ -460,7 +460,7 @@ where _address_ is an `IP` unicast address or a `DNS` resolvable name.
|
|||
The address of a remote reference server or local reference clock from which packets are to be received.
|
||||
|
||||
[[s2_Adding_a_Broadcast_or_Mutlticast_Server_Address]]
|
||||
===== Adding a Broadcast or Multicast Server Address
|
||||
=== Adding a Broadcast or Multicast Server Address
|
||||
|
||||
To add a broadcast or multicast address for sending, that is to say, the address to broadcast or multicast `NTP` packets to, make use of the [command]#broadcast# command in the `ntp.conf` file.
|
||||
|
||||
|
|
@ -478,7 +478,7 @@ where _address_ is an `IP` broadcast or multicast address to which packets are s
|
|||
This command configures a system to act as an `NTP` broadcast server. The address used must be a broadcast or a multicast address. Broadcast address implies the `IPv4` address `255.255.255.255`. By default, routers do not pass broadcast messages. The multicast address can be an `IPv4` Class D address, or an `IPv6` address. The IANA has assigned `IPv4` multicast address `224.0.1.1` and `IPv6` address `FF05::101` (site local) to `NTP`. Administratively scoped `IPv4` multicast addresses can also be used, as described in [citetitle]_link:++http://www.rfc-editor.org/info/rfc2365++[RFC 2365 Administratively Scoped IP Multicast]_.
|
||||
|
||||
[[s2_Adding_a_Manycast_Client_Address]]
|
||||
===== Adding a Manycast Client Address
|
||||
=== Adding a Manycast Client Address
|
||||
|
||||
To add a manycast client address, that is to say, to configure a multicast address to be used for `NTP` server discovery, make use of the [command]#manycastclient# command in the `ntp.conf` file.
|
||||
|
||||
|
|
@ -495,7 +495,7 @@ The client will send a request to the address and select the best servers from t
|
|||
This command configures a system to act as an `NTP` client. Systems can be both client and server at the same time.
|
||||
|
||||
[[s2_Adding_a_Broadcastclient_Address]]
|
||||
===== Adding a Broadcast Client Address
|
||||
=== Adding a Broadcast Client Address
|
||||
|
||||
To add a broadcast client address, that is to say, to configure a broadcast address to be monitored for broadcast `NTP` packets, make use of the [command]#broadcastclient# command in the `ntp.conf` file.
|
||||
|
||||
|
|
@ -511,7 +511,7 @@ Enables the receiving of broadcast messages. Requires authentication by default.
|
|||
This command configures a system to act as an `NTP` client. Systems can be both client and server at the same time.
|
||||
|
||||
[[s2_Adding_a_manycastserver_Address]]
|
||||
===== Adding a Manycast Server Address
|
||||
=== Adding a Manycast Server Address
|
||||
|
||||
To add a manycast server address, that is to say, to configure an address to allow the clients to discover the server by multicasting `NTP` packets, make use of the [command]#manycastserver# command in the `ntp.conf` file.
|
||||
|
||||
|
|
@ -527,7 +527,7 @@ Enables the sending of multicast messages. Where _address_ is the address to mul
|
|||
This command configures a system to act as an `NTP` server. Systems can be both client and server at the same time.
|
||||
|
||||
[[s2_Adding_a_multicastclient_Address]]
|
||||
===== Adding a Multicast Client Address
|
||||
=== Adding a Multicast Client Address
|
||||
|
||||
To add a multicast client address, that is to say, to configure a multicast address to be monitored for multicast `NTP` packets, make use of the [command]#multicastclient# command in the `ntp.conf` file.
|
||||
|
||||
|
|
@ -543,7 +543,7 @@ Enables the receiving of multicast messages. Where _address_ is the address to s
|
|||
This command configures a system to act as an `NTP` client. Systems can be both client and server at the same time.
|
||||
|
||||
[[s2_Configuring_the_burst_option]]
|
||||
===== Configuring the Burst Option
|
||||
=== Configuring the Burst Option
|
||||
|
||||
Using the [command]#burst# option against a public server is considered abuse. Do not use this option with public `NTP` servers. Use it only for applications within your own organization.
|
||||
|
||||
|
|
@ -557,7 +557,7 @@ To increase the average quality of time offset statistics, add the following opt
|
|||
At every poll interval, when the server responds, the system will send a burst of up to eight packets instead of the usual one packet. For use with the [command]#server# command to improve the average quality of the time-offset calculations.
|
||||
|
||||
[[s2_Configuring_the_iburst_Option]]
|
||||
===== Configuring the iburst Option
|
||||
=== Configuring the iburst Option
|
||||
|
||||
To improve the time taken for initial synchronization, add the following option to the end of a server command:
|
||||
|
||||
|
|
@ -569,7 +569,7 @@ To improve the time taken for initial synchronization, add the following option
|
|||
At every poll interval, send a burst of eight packets instead of one. When the server is not responding, packets are sent 16s apart. When the server responds, packets are sent every 2s. For use with the [command]#server# command to reduce the time taken for initial synchronization. This is now a default option in the configuration file.
|
||||
|
||||
[[s2_Configuring_Symmetric_Authentication_Using_a_Key]]
|
||||
===== Configuring Symmetric Authentication Using a Key
|
||||
=== Configuring Symmetric Authentication Using a Key
|
||||
|
||||
To configure symmetric authentication using a key, add the following option to the end of a server or peer command:
|
||||
|
||||
|
|
@ -593,7 +593,7 @@ manycastclient 239.255.254.254 key 30
|
|||
See also xref:Configuring_NTP_Using_ntpd.adoc#s1-Authentication_Options_for_NTP[Authentication Options for NTP].
|
||||
|
||||
[[s2_Configuring_the_Poll_Interval]]
|
||||
===== Configuring the Poll Interval
|
||||
=== Configuring the Poll Interval
|
||||
|
||||
To change the default poll interval, add the following options to the end of a server or peer command:
|
||||
|
||||
|
|
@ -605,7 +605,7 @@ To change the default poll interval, add the following options to the end of a s
|
|||
Options to change the default poll interval, where the interval in seconds will be calculated by raising 2 to the power of _value_, in other words, the interval is expressed in _log2_ seconds. The default [option]`minpoll` value is 6, _2pass:attributes[{blank}]^6^pass:attributes[{blank}]_ equates to 64s. The default value for [option]`maxpoll` is 10, which equates to 1024s. Allowed values are in the range 3 to 17 inclusive, which equates to 8s to 36.4h respectively. These options are for use with the [command]#peer# or [command]#server#. Setting a shorter [option]`maxpoll` may improve clock accuracy.
|
||||
|
||||
[[s2_Configuring_Server_Preference]]
|
||||
===== Configuring Server Preference
|
||||
=== Configuring Server Preference
|
||||
|
||||
To specify that a particular server should be preferred above others of similar statistical quality, add the following option to the end of a server or peer command:
|
||||
|
||||
|
|
@ -617,7 +617,7 @@ To specify that a particular server should be preferred above others of similar
|
|||
Use this server for synchronization in preference to other servers of similar statistical quality. This option is for use with the [command]#peer# or [command]#server# commands.
|
||||
|
||||
[[s2_Configuring_the_Time-To-Live_for_NTP_Packets]]
|
||||
===== Configuring the Time-to-Live for NTP Packets
|
||||
=== Configuring the Time-to-Live for NTP Packets
|
||||
|
||||
To specify that a particular _time-to-live_ (*TTL*) value should be used in place of the default, add the following option to the end of a server or peer command:
|
||||
|
||||
|
|
@ -629,7 +629,7 @@ To specify that a particular _time-to-live_ (*TTL*) value should be used in plac
|
|||
Specify the time-to-live value to be used in packets sent by broadcast servers and multicast `NTP` servers. Specify the maximum time-to-live value to use for the "expanding ring search" by a manycast client. The default value is `127`.
|
||||
|
||||
[[s2_Configuring_The_Version_of_NTP_to_use]]
|
||||
===== Configuring the NTP Version to Use
|
||||
=== Configuring the NTP Version to Use
|
||||
|
||||
To specify that a particular version of `NTP` should be used in place of the default, add the following option to the end of a server or peer command:
|
||||
|
||||
|
|
@ -641,7 +641,7 @@ To specify that a particular version of `NTP` should be used in place of the def
|
|||
Specify the version of `NTP` set in created `NTP` packets. The value can be in the range `1` to `4`. The default is `4`.
|
||||
|
||||
[[s1-Configuring_the_Hardware_Clock_update]]
|
||||
==== Configuring the Hardware Clock Update
|
||||
== Configuring the Hardware Clock Update
|
||||
|
||||
To configure the system clock to update the hardware clock, also known as the real-time clock (RTC), once after executing [application]*ntpdate*, add the following line to `/etc/sysconfig/ntpdate`:
|
||||
|
||||
|
|
@ -659,7 +659,7 @@ To update the hardware clock from the system clock, issue the following command
|
|||
When the system clock is being synchronized by `ntpd` or `chronyd`, the kernel will in turn update the RTC every 11 minutes automatically.
|
||||
|
||||
[[s1-Configuring_Clock_Sources]]
|
||||
==== Configuring Clock Sources
|
||||
== Configuring Clock Sources
|
||||
|
||||
To list the available clock sources on your system, issue the following commands:
|
||||
|
||||
|
|
@ -700,12 +700,12 @@ Rebuild the `grub.cfg` file as follows:
|
|||
----
|
||||
|
||||
[[s1-ntpd_additional-resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
|
||||
The following sources of information provide additional resources regarding `NTP` and `ntpd`.
|
||||
|
||||
[[s2-ntpd-docs-inst]]
|
||||
===== Installed Documentation
|
||||
=== Installed Documentation
|
||||
|
||||
* `ntpd(8)` man page — Describes `ntpd` in detail, including the command line options.
|
||||
|
||||
|
|
@ -736,7 +736,7 @@ The following sources of information provide additional resources regarding `NTP
|
|||
* `tickadj(8)` man page — Describes a utility for reading, and optionally setting, the length of the tick.
|
||||
|
||||
[[s2-ntpd_useful-websites]]
|
||||
===== Useful Websites
|
||||
=== Useful Websites
|
||||
|
||||
link:++http://doc.ntp.org/++[]:: The NTP Documentation Archive
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-Configuring_NTP_Using_the_chrony_Suite]]
|
||||
=== Configuring NTP Using the chrony Suite
|
||||
= Configuring NTP Using the chrony Suite
|
||||
|
||||
Accurate time keeping is important for a number of reasons in IT. In networking for example, accurate time stamps in packets and logs are required. In Linux systems, the `NTP` protocol is implemented by a daemon running in user space.
|
||||
|
||||
|
|
@ -12,12 +12,12 @@ The user space daemon updates the system clock running in the kernel. The system
|
|||
There is a choice between the daemons `ntpd` and `chronyd`, which are available from the repositories in the [package]*ntp* and [package]*chrony* packages respectively. This section describes the use of the [application]*chrony* suite of utilities to update the system clock on systems that do not fit into the conventional permanently networked, always on, dedicated server category.
|
||||
|
||||
[[sect-Introduction_to_the_chrony_Suite]]
|
||||
==== Introduction to the chrony Suite
|
||||
== Introduction to the chrony Suite
|
||||
|
||||
[application]*Chrony* consists of `chronyd`, a daemon that runs in user space, and [application]*chronyc*, a command line program for making adjustments to `chronyd`. Systems which are not permanently connected, or not permanently powered up, take a relatively long time to adjust their system clocks with `ntpd`. This is because many small corrections are made based on observations of the clocks drift and offset. Temperature changes, which may be significant when powering up a system, affect the stability of hardware clocks. Although adjustments begin within a few milliseconds of booting a system, acceptable accuracy may take anything from ten seconds from a warm restart to a number of hours depending on your requirements, operating environment and hardware. [application]*chrony* is a different implementation of the `NTP` protocol than `ntpd`, it can adjust the system clock more rapidly.
|
||||
|
||||
[[sect-differences_between_ntpd_and_chronyd]]
|
||||
===== Differences Between ntpd and chronyd
|
||||
=== Differences Between ntpd and chronyd
|
||||
|
||||
One of the main differences between `ntpd` and `chronyd` is in the algorithms used to control the computer's clock. Things `chronyd` can do better than `ntpd` are:
|
||||
|
||||
|
|
@ -46,27 +46,27 @@ Things `ntpd` can do that `chronyd` cannot do:
|
|||
* `ntpd` includes drivers for many reference clocks whereas `chronyd` relies on other programs, for example [application]*gpsd*, to access the data from the reference clocks.
|
||||
|
||||
[[sect-Choosing_between_NTP_daemon]]
|
||||
===== Choosing Between NTP Daemons
|
||||
=== Choosing Between NTP Daemons
|
||||
|
||||
* [application]*Chrony* should be considered for all systems which are frequently suspended or otherwise intermittently disconnected and reconnected to a network. Mobile and virtual systems for example.
|
||||
|
||||
* The `NTP` daemon (`ntpd`) should be considered for systems which are normally kept permanently on. Systems which are required to use broadcast or multicast `IP`, or to perform authentication of packets with the `Autokey` protocol, should consider using `ntpd`. [application]*Chrony* only supports symmetric key authentication using a message authentication code (MAC) with MD5, SHA1 or stronger hash functions, whereas `ntpd` also supports the `Autokey` authentication protocol which can make use of the PKI system. `Autokey` is described in [citetitle]_RFC 5906_.
|
||||
|
||||
[[sect-Understanding_chrony_and-its_configuration]]
|
||||
==== Understanding chrony and Its Configuration
|
||||
== Understanding chrony and Its Configuration
|
||||
|
||||
[[sect-Understanding_chronyd]]
|
||||
===== Understanding chronyd
|
||||
=== Understanding chronyd
|
||||
|
||||
The [application]*chrony* daemon, `chronyd`, running in user space, makes adjustments to the system clock which is running in the kernel. It does this by consulting external time sources, using the `NTP` protocol, when ever network access allows it to do so. When external references are not available, `chronyd` will use the last calculated drift stored in the drift file. It can also be commanded manually to make corrections, by [application]*chronyc*.
|
||||
|
||||
[[sect-Understanding_chronyc]]
|
||||
===== Understanding chronyc
|
||||
=== Understanding chronyc
|
||||
|
||||
The [application]*chrony* daemon, `chronyd`, can be controlled by the command line utility [application]*chronyc*. This utility provides a command prompt which allows entering of a number of commands to make changes to `chronyd`. The default configuration is for `chronyd` to only accept commands from a local instance of [application]*chronyc*, but [application]*chronyc* can be used to alter the configuration so that `chronyd` will allow external control. [application]*chronyc* can be run remotely after first configuring `chronyd` to accept remote connections. The `IP` addresses allowed to connect to `chronyd` should be tightly controlled.
|
||||
|
||||
[[sect-Understanding_the_chrony_configuration_commands]]
|
||||
===== Understanding the chrony Configuration Commands
|
||||
=== Understanding the chrony Configuration Commands
|
||||
|
||||
The default configuration file for `chronyd` is `/etc/chrony.conf`. The [option]`-f` option can be used to specify an alternate configuration file path. See the `chronyd` man page for further options. For a complete list of the directives that can be used see [citetitle]_link:++http://chrony.tuxfamily.org/manual.html#Configuration-file++[http://chrony.tuxfamily.org/manual.html#Configuration-file]_. Below is a selection of configuration options:
|
||||
|
||||
|
|
@ -219,7 +219,7 @@ rtcfile /var/lib/chrony/rtc
|
|||
rtcsync:: The [command]#rtcsync# directive is present in the `/etc/chrony.conf` file by default. This will inform the kernel the system clock is kept synchronized and the kernel will update the real-time clock every 11 minutes.
|
||||
|
||||
[[sect-Security_with_chronyc]]
|
||||
===== Security with chronyc
|
||||
=== Security with chronyc
|
||||
|
||||
As access to [application]*chronyc* allows changing `chronyd` just as editing the configuration files would, access to [application]*chronyc* should be limited. Passwords can be specified in the key file, written in ASCII or HEX, to restrict the use of [application]*chronyc*. One of the entries is used to restrict the use of operational commands and is referred to as the command key. In the default configuration, a random command key is generated automatically on start. It should not be necessary to specify or alter it manually.
|
||||
|
||||
|
|
@ -306,10 +306,10 @@ Only the following commands can be used without providing a password:
|
|||
.
|
||||
|
||||
[[sect-Using_chrony]]
|
||||
==== Using chrony
|
||||
== Using chrony
|
||||
|
||||
[[sect-Installing_chrony]]
|
||||
===== Installing chrony
|
||||
=== Installing chrony
|
||||
|
||||
The [application]*chrony* suite is installed by default on some versions of Fedora. If required, to ensure that it is, run the following command as `root`:
|
||||
|
||||
|
|
@ -321,7 +321,7 @@ The [application]*chrony* suite is installed by default on some versions of Fedo
|
|||
The default location for the [application]*chrony* daemon is `/usr/sbin/chronyd`. The command line utility will be installed to `/usr/bin/chronyc`.
|
||||
|
||||
[[sect-Checking_the_Status_of_chronyd]]
|
||||
===== Checking the Status of chronyd
|
||||
=== Checking the Status of chronyd
|
||||
|
||||
To check the status of `chronyd`, issue the following command:
|
||||
|
||||
|
|
@ -334,7 +334,7 @@ chronyd.service - NTP client/server
|
|||
----
|
||||
|
||||
[[sect-Starting_chronyd]]
|
||||
===== Starting chronyd
|
||||
=== Starting chronyd
|
||||
|
||||
To start `chronyd`, issue the following command as `root`:
|
||||
|
||||
|
|
@ -351,7 +351,7 @@ To ensure `chronyd` starts automatically at system start, issue the following co
|
|||
----
|
||||
|
||||
[[sect-Stopping_chronyd]]
|
||||
===== Stopping chronyd
|
||||
=== Stopping chronyd
|
||||
|
||||
To stop `chronyd`, issue the following command as `root`:
|
||||
|
||||
|
|
@ -368,12 +368,12 @@ To prevent `chronyd` from starting automatically at system start, issue the foll
|
|||
----
|
||||
|
||||
[[sect-Checking_if_chrony_is_synchronized]]
|
||||
===== Checking if chrony is Synchronized
|
||||
=== Checking if chrony is Synchronized
|
||||
|
||||
To check if [application]*chrony* is synchronized, make use of the [command]#tracking#, [command]#sources#, and [command]#sourcestats# commands.
|
||||
|
||||
[[sect-Checking_chrony_tracking]]
|
||||
====== Checking chrony Tracking
|
||||
==== Checking chrony Tracking
|
||||
|
||||
To check [application]*chrony* tracking, issue the following command:
|
||||
|
||||
|
|
@ -427,7 +427,7 @@ Root dispersion:: This is the total dispersion accumulated through all the comp
|
|||
Leap status:: This is the leap status, which can be Normal, Insert second, Delete second or Not synchronized.
|
||||
|
||||
[[sect-Checking_chrony_sources]]
|
||||
====== Checking chrony Sources
|
||||
==== Checking chrony Sources
|
||||
|
||||
The sources command displays information about the current time sources that `chronyd` is accessing.
|
||||
|
||||
|
|
@ -466,7 +466,7 @@ LastRx:: This column shows how long ago the last sample was received from the so
|
|||
Last sample:: This column shows the offset between the local clock and the source at the last measurement. The number in the square brackets shows the actual measured offset. This may be suffixed by `ns` (indicating nanoseconds), `us` (indicating microseconds), `ms` (indicating milliseconds), or `s` (indicating seconds). The number to the left of the square brackets shows the original measurement, adjusted to allow for any slews applied to the local clock since. The number following the `+/-` indicator shows the margin of error in the measurement. Positive offsets indicate that the local clock is ahead of the source.
|
||||
|
||||
[[sect-Checking_chrony_Source_Statistics]]
|
||||
====== Checking chrony Source Statistics
|
||||
==== Checking chrony Source Statistics
|
||||
|
||||
The [command]#sourcestats# command displays information about the drift rate and offset estimation process for each of the sources currently being examined by `chronyd`.
|
||||
|
||||
|
|
@ -500,7 +500,7 @@ Offset:: This is the estimated offset of the source.
|
|||
Std Dev:: This is the estimated sample standard deviation.
|
||||
|
||||
[[sect-Manually_Adjusting-the-System_Clock]]
|
||||
===== Manually Adjusting the System Clock
|
||||
=== Manually Adjusting the System Clock
|
||||
|
||||
To update, or step, the system clock immediately, bypassing any adjustments in progress by slewing the clock, issue the following commands as `root`:
|
||||
|
||||
|
|
@ -525,10 +525,10 @@ chronyc -a makestep
|
|||
----
|
||||
|
||||
[[sect-Setting_up_chrony_for_different_environments]]
|
||||
==== Setting Up chrony for Different Environments
|
||||
== Setting Up chrony for Different Environments
|
||||
|
||||
[[sect-Setting_up_chrony_for_a_system_which_is_infrequently_connected]]
|
||||
===== Setting Up chrony for a System Which is Infrequently Connected
|
||||
=== Setting Up chrony for a System Which is Infrequently Connected
|
||||
|
||||
This example is intended for systems which use dial-on-demand connections. The normal configuration should be sufficient for mobile and virtual devices which connect intermittently. First, review and confirm that the default settings in the `/etc/chrony.conf` are similar to the following:
|
||||
|
||||
|
|
@ -555,7 +555,7 @@ server 3.pool.ntp.org offline
|
|||
The [option]`offline` option can be useful in preventing systems from trying to activate connections. The [application]*chrony* daemon will wait for [application]*chronyc* to inform it that the system is connected to the network or Internet.
|
||||
|
||||
[[sect-Setting_up_chrony_for_a_system_in_an_isolated_network]]
|
||||
===== Setting Up chrony for a System in an Isolated Network
|
||||
=== Setting Up chrony for a System in an Isolated Network
|
||||
|
||||
For a network that is never connected to the Internet, one computer is selected to be the master timeserver. The other computers are either direct clients of the master, or clients of clients. On the master, the drift file must be manually set with the average rate of drift of the system clock. If the master is rebooted it will obtain the time from surrounding systems and take an average to set its system clock. Thereafter it resumes applying adjustments based on the drift file. The drift file will be updated automatically when the [command]#settime# command is used.
|
||||
|
||||
|
|
@ -596,10 +596,10 @@ Where `192.0.2.123` is the address of the master, and `master` is the host name
|
|||
On the client systems which are not to be direct clients of the master, the `/etc/chrony.conf` file should be the same except that the [option]`local` and [option]`allow` directives should be omitted.
|
||||
|
||||
[[sect-Using_chronyc]]
|
||||
==== Using chronyc
|
||||
== Using chronyc
|
||||
|
||||
[[sect-Using_chronyc_chronyc_to_control_chronyd]]
|
||||
===== Using chronyc to Control chronyd
|
||||
=== Using chronyc to Control chronyd
|
||||
|
||||
To make changes to the local instance of `chronyd` using the command line utility [application]*chronyc* in interactive mode, enter the following command as `root`:
|
||||
|
||||
|
|
@ -634,7 +634,7 @@ Changes made using [application]*chronyc* are not permanent, they will be lost a
|
|||
====
|
||||
|
||||
[[sect-Using_chronyc_for_remote_administration]]
|
||||
===== Using chronyc for Remote Administration
|
||||
=== Using chronyc for Remote Administration
|
||||
|
||||
To configure [application]*chrony* to connect to a remote instance of `chronyd`, issue a command in the following format:
|
||||
|
||||
|
|
@ -678,12 +678,12 @@ chronyc> [command]#password HEX:A6CFC50C9C93AB6E5A19754C246242FC5471BCDF#
|
|||
The password or hash associated with the command key for a remote system is best obtained by `SSH`. An `SSH` connection should be established to the remote machine and the ID of the command key from `/etc/chrony.conf` and the command key in `/etc/chrony.keys` memorized or stored securely for the duration of the session.
|
||||
|
||||
[[sect-additional_resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
|
||||
The following sources of information provide additional resources regarding [application]*chrony*.
|
||||
|
||||
[[s2-chrony-docs-inst]]
|
||||
===== Installed Documentation
|
||||
=== Installed Documentation
|
||||
|
||||
* `chrony(1)` man page — Introduces the [application]*chrony* daemon and the command-line interface tool.
|
||||
|
||||
|
|
@ -696,6 +696,6 @@ The following sources of information provide additional resources regarding [app
|
|||
* `/usr/share/doc/chrony/chrony.txt` — User guide for the [application]*chrony* suite.
|
||||
|
||||
[[s2-chrony_Online_Documentation]]
|
||||
===== Online Documentation
|
||||
=== Online Documentation
|
||||
|
||||
link:++http://chrony.tuxfamily.org/manual.html++[]:: The online user guide for [application]*chrony*.
|
||||
|
|
|
|||
|
|
@ -3,17 +3,17 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-Configuring_PTP_Using_ptp4l]]
|
||||
=== Configuring PTP Using ptp4l
|
||||
= Configuring PTP Using ptp4l
|
||||
|
||||
[[sec-Introduction_to_PTP]]
|
||||
==== Introduction to PTP
|
||||
== Introduction to PTP
|
||||
|
||||
The _Precision Time Protocol_ (*PTP*) is a protocol used to synchronize clocks in a network. When used in conjunction with hardware support, `PTP` is capable of sub-microsecond accuracy, which is far better than is normally obtainable with `NTP`. `PTP` support is divided between the kernel and user space. The kernel in Fedora includes support for `PTP` clocks, which are provided by network drivers. The actual implementation of the protocol is known as [application]*linuxptp*, a `PTPv2` implementation according to the IEEE standard 1588 for Linux.
|
||||
|
||||
The [package]*linuxptp* package includes the [application]*ptp4l* and [application]*phc2sys* programs for clock synchronization. The [application]*ptp4l* program implements the `PTP` boundary clock and ordinary clock. With hardware time stamping, it is used to synchronize the `PTP` hardware clock to the master clock, and with software time stamping it synchronizes the system clock to the master clock. The [application]*phc2sys* program is needed only with hardware time stamping, for synchronizing the system clock to the `PTP` hardware clock on the _network interface card_ (*NIC*).
|
||||
|
||||
[[sec-Understanding_PTP]]
|
||||
===== Understanding PTP
|
||||
=== Understanding PTP
|
||||
|
||||
The clocks synchronized by `PTP` are organized in a master-slave hierarchy. The slaves are synchronized to their masters which may be slaves to their own masters. The hierarchy is created and updated automatically by the _best master clock_ (*BMC*) algorithm, which runs on every clock. When a clock has only one port, it can be _master_ or _slave_, such a clock is called an _ordinary clock_ (*OC*). A clock with multiple ports can be master on one port and slave on another, such a clock is called a _boundary_ clock (*BC*). The top-level master is called the _grandmaster clock_, which can be synchronized by using a _Global Positioning System_ (*GPS*) time source. By using a GPS-based time source, disparate networks can be synchronized with a high-degree of accuracy.
|
||||
|
||||
|
|
@ -23,19 +23,19 @@ The clocks synchronized by `PTP` are organized in a master-slave hierarchy. The
|
|||
image::ptp_grandmaster_boundary_and_slaves.png[An illustration showing PTP grandmaster, boundary, and slave clocks]
|
||||
|
||||
[[sec-Advantages_of_PTP]]
|
||||
===== Advantages of PTP
|
||||
=== Advantages of PTP
|
||||
|
||||
One of the main advantages that `PTP` has over the _Network Time Protocol_ (*NTP*) is hardware support present in various _network interface controllers_ (*NIC*) and network switches. This specialized hardware allows `PTP` to account for delays in message transfer, and greatly improves the accuracy of time synchronization. While it is possible to use non-PTP enabled hardware components within the network, this will often cause an increase in jitter or introduce an asymmetry in the delay resulting in synchronization inaccuracies, which add up with multiple non-PTP aware components used in the communication path. To achieve the best possible accuracy, it is recommended that all networking components between `PTP` clocks are `PTP` hardware enabled. Time synchronization in larger networks where not all of the networking hardware supports `PTP` might be better suited for `NTP`.
|
||||
|
||||
With hardware `PTP` support, the NIC has its own on-board clock, which is used to time stamp the received and transmitted `PTP` messages. It is this on-board clock that is synchronized to the `PTP` master, and the computer's system clock is synchronized to the `PTP` hardware clock on the NIC. With software `PTP` support, the system clock is used to time stamp the `PTP` messages and it is synchronized to the `PTP` master directly. Hardware `PTP` support provides better accuracy since the NIC can time stamp the `PTP` packets at the exact moment they are sent and received while software `PTP` support requires additional processing of the `PTP` packets by the operating system.
|
||||
|
||||
[[sec-Using_PTP]]
|
||||
==== Using PTP
|
||||
== Using PTP
|
||||
|
||||
In order to use `PTP`, the kernel network driver for the intended interface has to support either software or hardware time stamping capabilities.
|
||||
|
||||
[[sec-Checking_for_Driver_and_Hardware_Support]]
|
||||
===== Checking for Driver and Hardware Support
|
||||
=== Checking for Driver and Hardware Support
|
||||
|
||||
In addition to hardware time stamping support being present in the driver, the NIC must also be capable of supporting this functionality in the physical hardware. The best way to verify the time stamping capabilities of a particular driver and NIC is to use the [application]*ethtool* utility to query the interface as follows:
|
||||
|
||||
|
|
@ -80,7 +80,7 @@ should include:
|
|||
* `SOF_TIMESTAMPING_RX_HARDWARE`
|
||||
|
||||
[[sec-Installing_PTP]]
|
||||
===== Installing PTP
|
||||
=== Installing PTP
|
||||
|
||||
The kernel in Fedora includes support for `PTP`. User space support is provided by the tools in the [application]*linuxptp* package. To install [application]*linuxptp*, issue the following command as `root`:
|
||||
|
||||
|
|
@ -94,7 +94,7 @@ This will install [application]*ptp4l* and [application]*phc2sys*.
|
|||
Do not run more than one service to set the system clock's time at the same time. If you intend to serve `PTP` time using `NTP`, see xref:Configuring_PTP_Using_ptp4l.adoc#sec-Serving_PTP_Time_with_NTP[Serving PTP Time with NTP].
|
||||
|
||||
[[sec-Starting_ptp4l]]
|
||||
===== Starting ptp4l
|
||||
=== Starting ptp4l
|
||||
|
||||
The [application]*ptp4l* program can be started from the command line or it can be started as a service. When running as a service, options are specified in the `/etc/sysconfig/ptp4l` file. Options required for use both by the service and on the command line should be specified in the `/etc/ptp4l.conf` file. The `/etc/sysconfig/ptp4l` file includes the [command]#-f /etc/ptp4l.conf# command line option, which causes the `ptp4l` program to read the `/etc/ptp4l.conf` file and process the options it contains. The use of the `/etc/ptp4l.conf` is explained in xref:Configuring_PTP_Using_ptp4l.adoc#sec-Specifying_a_Configuration_File[Specifying a Configuration File]. More information on the different [application]*ptp4l* options and the configuration file settings can be found in the `ptp4l(8)` man page.
|
||||
|
||||
|
|
@ -156,7 +156,7 @@ To enable software time stamping, the [option]`-S` option needs to be used as fo
|
|||
----
|
||||
|
||||
[[sec-Selecting_a_Delay_Mechanism]]
|
||||
====== Selecting a Delay Measurement Mechanism
|
||||
==== Selecting a Delay Measurement Mechanism
|
||||
|
||||
There are two different delay measurement mechanisms and they can be selected by means of an option added to the [command]#ptp4l# command as follows:
|
||||
|
||||
|
|
@ -184,7 +184,7 @@ All clocks on a single `PTP` communication path must use the same mechanism to m
|
|||
====
|
||||
|
||||
[[sec-Specifying_a_Configuration_File]]
|
||||
==== Specifying a Configuration File
|
||||
== Specifying a Configuration File
|
||||
|
||||
The command line options and other options, which cannot be set on the command line, can be set in an optional configuration file.
|
||||
|
||||
|
|
@ -208,7 +208,7 @@ time_stamping software
|
|||
----
|
||||
|
||||
[[sec-Using_the_PTP_Management_Client]]
|
||||
==== Using the PTP Management Client
|
||||
== Using the PTP Management Client
|
||||
|
||||
The `PTP` management client, [application]*pmc*, can be used to obtain additional information from [application]*ptp4l* as follows:
|
||||
|
||||
|
|
@ -259,7 +259,7 @@ For a full list of [application]*pmc* commands, type the following as `root`:
|
|||
Additional information is available in the `pmc(8)` man page.
|
||||
|
||||
[[sec-Synchronizing_the_Clocks]]
|
||||
==== Synchronizing the Clocks
|
||||
== Synchronizing the Clocks
|
||||
|
||||
The [application]*phc2sys* program is used to synchronize the system clock to the `PTP` hardware clock (*PHC*) on the NIC. The [application]*phc2sys* service is configured in the `/etc/sysconfig/phc2sys` configuration file. The default setting in the `/etc/sysconfig/phc2sys` file is as follows:
|
||||
|
||||
|
|
@ -317,7 +317,7 @@ When running as a service, options are specified in the `/etc/sysconfig/phc2sys`
|
|||
Note that the examples in this section assume the command is run on a slave system or slave port.
|
||||
|
||||
[[sec-Verifying_Time_Synchronization]]
|
||||
==== Verifying Time Synchronization
|
||||
== Verifying Time Synchronization
|
||||
|
||||
When `PTP` time synchronization is working properly, new messages with offsets and frequency adjustments will be printed periodically to the [application]*ptp4l* and [application]*phc2sys* (if hardware time stamping is used) outputs. These values will eventually converge after a short period of time. These messages can be seen in `/var/log/messages` file. An example of the output follows:
|
||||
|
||||
|
|
@ -427,7 +427,7 @@ phc2sys[1060.984]: rms 266 max 675 freq -36759 ± 234 delay 2753 ± 17
|
|||
----
|
||||
|
||||
[[sec-Serving_PTP_Time_with_NTP]]
|
||||
==== Serving PTP Time with NTP
|
||||
== Serving PTP Time with NTP
|
||||
|
||||
The `ntpd` daemon can be configured to distribute the time from the system clock synchronized by [application]*ptp4l* or [application]*phc2sys* by using the LOCAL reference clock driver. To prevent `ntpd` from adjusting the system clock, the `ntp.conf` file must not specify any `NTP` servers. The following is a minimal example of `ntp.conf`:
|
||||
|
||||
|
|
@ -447,7 +447,7 @@ When the `DHCP` client program, [application]*dhclient*, receives a list of `NTP
|
|||
====
|
||||
|
||||
[[sec-Serving_NTP_Time_with_PTP]]
|
||||
==== Serving NTP Time with PTP
|
||||
== Serving NTP Time with PTP
|
||||
|
||||
`NTP` to `PTP` synchronization in the opposite direction is also possible. When `ntpd` is used to synchronize the system clock, [application]*ptp4l* can be configured with the [option]`priority1` option (or other clock options included in the best master clock algorithm) to be the grandmaster clock and distribute the time from the system clock via `PTP`:
|
||||
|
||||
|
|
@ -490,14 +490,14 @@ To prevent quick changes in the `PTP` clock's frequency, the synchronization to
|
|||
----
|
||||
|
||||
[[sec-Synchronize_to_PTP_or_NTP_Time_Using_timemaster]]
|
||||
==== Synchronize to PTP or NTP Time Using timemaster
|
||||
== Synchronize to PTP or NTP Time Using timemaster
|
||||
|
||||
When there are multiple `PTP` domains available on the network, or fallback to `NTP` is needed, the [application]*timemaster* program can be used to synchronize the system clock to all available time sources. The `PTP` time is provided by [application]*phc2sys* and [application]*ptp4l* via _shared memory driver_ (*SHM* reference clocks to `chronyd` or `ntpd` (depending on the `NTP` daemon that has been configured on the system). The `NTP` daemon can then compare all time sources, both `PTP` and `NTP`, and use the best sources to synchronize the system clock.
|
||||
|
||||
On start, [application]*timemaster* reads a configuration file that specifies the `NTP` and `PTP` time sources, checks which network interfaces have their own or share a `PTP` hardware clock (PHC), generates configuration files for [application]*ptp4l* and `chronyd` or `ntpd`, and starts the [application]*ptp4l*, [application]*phc2sys*, and `chronyd` or `ntpd` processes as needed. It will remove the generated configuration files on exit. It writes configuration files for `chronyd`, `ntpd`, and [application]*ptp4l* to `/var/run/timemaster/`.
|
||||
|
||||
[[sec-Starting_timemaster_as_a_Service]]
|
||||
===== Starting timemaster as a Service
|
||||
=== Starting timemaster as a Service
|
||||
|
||||
To start [application]*timemaster* as a service, issue the following command as `root`:
|
||||
|
||||
|
|
@ -509,7 +509,7 @@ To start [application]*timemaster* as a service, issue the following command as
|
|||
This will read the options in `/etc/timemaster.conf`.
|
||||
|
||||
[[sec-Understanding_the_timemaster_Configuration_File]]
|
||||
===== Understanding the timemaster Configuration File
|
||||
=== Understanding the timemaster Configuration File
|
||||
|
||||
{MAJOROS} provides a default `/etc/timemaster.conf` file with a number of sections containing default options. The section headings are enclosed in brackets.
|
||||
|
||||
|
|
@ -606,7 +606,7 @@ The section headings are as follows:
|
|||
The section headings and there contents are explained in detail in the `timemaster(8)` manual page.
|
||||
|
||||
[[sec-Configuring_timemaster_Options]]
|
||||
===== Configuring timemaster Options
|
||||
=== Configuring timemaster Options
|
||||
|
||||
[[proc-Editing_the_timemaster_Configuration_File]]
|
||||
.Editing the timemaster Configuration File
|
||||
|
|
@ -651,7 +651,7 @@ The section headings and there contents are explained in detail in the `timemast
|
|||
----
|
||||
|
||||
[[sec-Improving_Accuracy]]
|
||||
==== Improving Accuracy
|
||||
== Improving Accuracy
|
||||
|
||||
Previously, test results indicated that disabling the tickless kernel capability could significantly improve the stability of the system clock, and thus improve the `PTP` synchronization accuracy (at the cost of increased power consumption). The kernel tickless mode can be disabled by adding [option]`nohz=off` to the kernel boot option parameters. However, recent improvements applied to `kernel-3.10.0-197.fc21` have greatly improved the stability of the system clock and the difference in stability of the clock with and without [option]`nohz=off` should be much smaller now for most users.
|
||||
|
||||
|
|
@ -681,12 +681,12 @@ After making changes to `/etc/sysconfig/phc2sys`, restart the [application]*phc2
|
|||
----
|
||||
|
||||
[[sec-PTP_additional_resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
|
||||
The following sources of information provide additional resources regarding `PTP` and the [application]*ptp4l* tools.
|
||||
|
||||
[[sec-PTP-docs-inst]]
|
||||
===== Installed Documentation
|
||||
=== Installed Documentation
|
||||
|
||||
* `ptp4l(8)` man page — Describes [application]*ptp4l* options including the format of the configuration file.
|
||||
|
||||
|
|
@ -697,7 +697,7 @@ The following sources of information provide additional resources regarding `PTP
|
|||
* `timemaster(8)` man page — Describes a program that uses [application]*ptp4l* and [application]*phc2sys* to synchronize the system clock using `chronyd` or `ntpd`.
|
||||
|
||||
[[sec-PTP_useful-websites]]
|
||||
===== Useful Websites
|
||||
=== Useful Websites
|
||||
|
||||
link:++http://linuxptp.sourceforge.net/++[]:: The Linux PTP project.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,6 @@
|
|||
:experimental:
|
||||
|
||||
[[ch-Directory_Servers]]
|
||||
=== Directory Servers
|
||||
= Directory Servers
|
||||
|
||||
include::en-US/servers/OpenLDAP.adoc[]
|
||||
|
|
|
|||
|
|
@ -1,18 +1,18 @@
|
|||
|
||||
[[s1-FTP]]
|
||||
==== FTP
|
||||
== FTP
|
||||
indexterm:[FTP,definition of]indexterm:[FTP,vsftpd]
|
||||
_File Transfer Protocol_ (`FTP`) is one of the oldest and most commonly used protocols found on the Internet today. Its purpose is to reliably transfer files between computer hosts on a network without requiring the user to log directly into the remote host or have knowledge of how to use the remote system. It allows users to access files on remote systems using a standard set of simple commands.
|
||||
|
||||
This section outlines the basics of the `FTP` protocol, as well as configuration options for the primary `FTP` server shipped with {MAJOROS}, [command]#vsftpd#.
|
||||
|
||||
[[s2-ftp-protocol]]
|
||||
===== The File Transfer Protocol
|
||||
=== The File Transfer Protocol
|
||||
indexterm:[FTP,introducing]
|
||||
However, because `FTP` is so prevalent on the Internet, it is often required to share files to the public. System administrators, therefore, should be aware of the `FTP` protocol's unique characteristics.
|
||||
|
||||
[[s3-ftp-protocol-multiport]]
|
||||
====== Multiple Ports, Multiple Modes
|
||||
==== Multiple Ports, Multiple Modes
|
||||
indexterm:[FTP,command port]indexterm:[FTP,data port]indexterm:[FTP,active mode]indexterm:[FTP,passive mode]
|
||||
Unlike most protocols used on the Internet, `FTP` requires multiple network ports to work properly. When an `FTP` client application initiates a connection to an `FTP` server, it opens port 21 on the server — known as the _command port_. This port is used to issue all commands to the server. Any data requested from the server is returned to the client via a _data port_. The port number for data connections, and the way in which data connections are initialized, vary depending upon whether the client requests the data in _active_ or _passive_ mode.
|
||||
|
||||
|
|
@ -25,7 +25,7 @@ passive mode:: Passive mode, like active mode, is initiated by the `FTP` client
|
|||
While passive mode resolves issues for client-side firewall interference with data connections, it can complicate administration of the server-side firewall. You can reduce the number of open ports on a server by limiting the range of unprivileged ports on the `FTP` server. This also simplifies the process of configuring firewall rules for the server. See xref:File_and_Print_Servers.adoc#s3-ftp-vsftpd-conf-opt-net[Network Options] for more information about limiting passive ports.
|
||||
|
||||
[[s2-ftp-servers]]
|
||||
===== FTP Servers
|
||||
=== FTP Servers
|
||||
indexterm:[FTP,server software,vsftpd]indexterm:[FTP,server software,Red Hat Content Accelerator]indexterm:[vsftpd,FTP]indexterm:[vsftpd,security features]
|
||||
{MAJOROS} ships with two different `FTP` servers:
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ Use of these security practices has the following effect on how [command]#vsftpd
|
|||
* *Most interaction with `FTP` clients is handled by unprivileged child processes in a [command]#chroot# jail* — Because these child processes are unprivileged and only have access to the directory being shared, any crashed processes only allows the attacker access to the shared files.
|
||||
|
||||
[[s3-ftp-vsftpd-conf]]
|
||||
===== Files Installed with [command]#vsftpd#
|
||||
=== Files Installed with [command]#vsftpd#
|
||||
indexterm:[vsftpd,RPM,files installed by]
|
||||
The `vsftpd` RPM installs the daemon (`/usr/sbin/vsftpd`), its configuration and related files, as well as `FTP` directories onto the system. The following lists the files and directories related to [command]#vsftpd# configuration:
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ The `vsftpd` RPM installs the daemon (`/usr/sbin/vsftpd`), its configuration and
|
|||
* `/var/ftp/` — The directory containing files served by [command]#vsftpd#. It also contains the `/var/ftp/pub/` directory for anonymous users. Both directories are world-readable, but writable only by the `root` user.
|
||||
|
||||
[[s2-ftp-vsftpd-start]]
|
||||
===== Starting and Stopping [command]#vsftpd#
|
||||
=== Starting and Stopping [command]#vsftpd#
|
||||
indexterm:[vsftpd,starting]indexterm:[vsftpd,stopping]indexterm:[vsftpd,status]indexterm:[vsftpd,condrestart]indexterm:[vsftpd,restarting]
|
||||
The `vsftpd` RPM installs the `/etc/rc.d/init.d/vsftpd` script, which can be accessed using the [command]#systemctl# command.
|
||||
|
||||
|
|
@ -113,7 +113,7 @@ To conditionally restart the server, as `root` type:
|
|||
By default, the [command]#vsftpd# service does *not* start automatically at boot time. To configure the [command]#vsftpd# service to start at boot time, use a service manager such as [command]#systemctl#. See xref:../infrastructure-services/Services_and_Daemons.adoc#ch-Services_and_Daemons[Services and Daemons] for more information on how to configure services in {MAJOROS}.
|
||||
|
||||
[[s3-ftp-vsftpd-start-multi]]
|
||||
====== Starting Multiple Copies of [command]#vsftpd#
|
||||
==== Starting Multiple Copies of [command]#vsftpd#
|
||||
indexterm:[vsftpd,starting multiple copies of]indexterm:[vsftpd,multihome configuration]
|
||||
Sometimes one computer is used to serve multiple `FTP` domains. This is a technique called _multihoming_. One way to multihome using [command]#vsftpd# is by running multiple copies of the daemon, each with its own configuration file.
|
||||
|
||||
|
|
@ -160,7 +160,7 @@ For an overview of ways to secure [command]#vsftpd#, see the link:++https://acce
|
|||
The following is a list of some of the more important directives within `/etc/vsftpd/vsftpd.conf`. All directives not explicitly found or commented out within [command]#vsftpd#pass:attributes[{blank}]'s configuration file are set to their default value.
|
||||
|
||||
[[s3-ftp-vsftpd-conf-opt-daemon]]
|
||||
====== Daemon Options
|
||||
==== Daemon Options
|
||||
indexterm:[vsftpd,configuration file,daemon options]
|
||||
The following is a list of directives which control the overall behavior of the [command]#vsftpd# daemon.
|
||||
|
||||
|
|
@ -177,7 +177,7 @@ The default value is [command]#NO#.
|
|||
The default value is [command]#YES#.
|
||||
|
||||
[[s3-ftp-vsftpd-conf-opt-login]]
|
||||
====== Log In Options and Access Controls
|
||||
==== Log In Options and Access Controls
|
||||
indexterm:[vsftpd,configuration file,login options]indexterm:[vsftpd,configuration file,access controls]
|
||||
The following is a list of directives which control the login behavior and access control mechanisms.
|
||||
|
||||
|
|
@ -232,7 +232,7 @@ The default value is [command]#NO#, however under {MAJOROS} the value is set to
|
|||
The default value is [command]#/etc/vsftpd/user_list# and is created during installation.
|
||||
|
||||
[[s3-ftp-vsftpd-conf-opt-anon]]
|
||||
====== Anonymous User Options
|
||||
==== Anonymous User Options
|
||||
indexterm:[vsftpd,configuration file,anonymous user options]
|
||||
The following lists directives which control anonymous user access to the server. To use these options, the [command]#anonymous_enable# directive must be set to [command]#YES#.
|
||||
|
||||
|
|
@ -267,7 +267,7 @@ Anonymous logins are prevented unless the password provided is listed in [comman
|
|||
The default value is [command]#NO#.
|
||||
|
||||
[[s3-ftp-vsftpd-conf-opt-usr]]
|
||||
====== Local User Options
|
||||
==== Local User Options
|
||||
indexterm:[vsftpd,configuration file,local user options]
|
||||
The following lists directives which characterize the way local users access the server. To use these options, the [command]#local_enable# directive must be set to [command]#YES#.
|
||||
|
||||
|
|
@ -322,7 +322,7 @@ The default value is [command]#NO#.
|
|||
There is no default value for this directive.
|
||||
|
||||
[[s3-ftp-vsftpd-conf-opt-dir]]
|
||||
====== Directory Options
|
||||
==== Directory Options
|
||||
indexterm:[vsftpd,configuration file,directory options]
|
||||
The following lists directives which affect directories.
|
||||
|
||||
|
|
@ -355,7 +355,7 @@ The default value is [command]#NO#.
|
|||
The default value is [command]#NO#.
|
||||
|
||||
[[s3-ftp-vsftpd-conf-opt-file]]
|
||||
====== File Transfer Options
|
||||
==== File Transfer Options
|
||||
indexterm:[vsftpd,configuration file,file transfer options]
|
||||
The following lists directives which affect directories.
|
||||
|
||||
|
|
@ -376,7 +376,7 @@ The default value is [command]#root#.
|
|||
The default value is [command]#YES#.
|
||||
|
||||
[[s3-ftp-vsftpd-conf-opt-log]]
|
||||
====== Logging Options
|
||||
==== Logging Options
|
||||
indexterm:[vsftpd,configuration file,logging options]
|
||||
The following lists directives which affect [command]#vsftpd#pass:attributes[{blank}]'s logging behavior.
|
||||
|
||||
|
|
@ -421,7 +421,7 @@ If maintaining a [command]#wu-ftpd#-compatible file transfer log is not importan
|
|||
====
|
||||
|
||||
[[s3-ftp-vsftpd-conf-opt-net]]
|
||||
====== Network Options
|
||||
==== Network Options
|
||||
indexterm:[vsftpd,configuration file,network options]
|
||||
The following lists directives which affect how [command]#vsftpd# interacts with the network.
|
||||
|
||||
|
|
@ -526,12 +526,12 @@ The default value is [command]#NO#.
|
|||
The default value is [command]#YES#.
|
||||
|
||||
[[s2-ftp-resources]]
|
||||
===== Additional Resources
|
||||
=== Additional Resources
|
||||
indexterm:[vsftpd,additional resources]
|
||||
For more information about [command]#vsftpd#, refer to the following resources.
|
||||
|
||||
[[s3-ftp-installed-documentation]]
|
||||
====== Installed Documentation
|
||||
==== Installed Documentation
|
||||
indexterm:[vsftpd,additional resources,installed documentation]
|
||||
|
||||
* The `/usr/share/doc/vsftpd/` directory — This directory contains a `README` with basic information about the software. The `TUNING` file contains basic performance tuning tips and the `SECURITY/` directory contains information about the security model employed by [command]#vsftpd#.
|
||||
|
|
@ -549,7 +549,7 @@ Configuration Files:: {blank}
|
|||
*** [command]#man 5 hosts_access# — Describes the format and options available within the TCP wrappers configuration files: `hosts.allow` and `hosts.deny`.
|
||||
|
||||
[[s3-ftp-useful-websites]]
|
||||
====== Useful Websites
|
||||
==== Useful Websites
|
||||
indexterm:[vsftpd,additional resources,useful websites]
|
||||
|
||||
* link:++https://security.appspot.com/vsftpd.html++[https://security.appspot.com/vsftpd.html] — The [command]#vsftpd# project page is a great place to locate the latest documentation and to contact the author of the software.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-File_and_Print_Servers]]
|
||||
=== File and Print Servers
|
||||
= File and Print Servers
|
||||
|
||||
This chapter guides you through the installation and configuration of [application]*Samba*, an open source implementation of the _Server Message Block_ (*SMB*) and _common Internet file system_ (`CIFS`) protocol, and [application]*vsftpd*, the primary FTP server shipped with {MAJOROS}. Additionally, it explains how to use the [application]*Printer* tool to configure printers.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,12 +3,12 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-Mail_Servers]]
|
||||
=== Mail Servers
|
||||
= Mail Servers
|
||||
|
||||
{MAJOROS} offers many advanced applications to serve and access email. This chapter describes modern email protocols in use today, and some of the programs designed to send and receive email.
|
||||
|
||||
[[s1-email-protocols]]
|
||||
==== Email Protocols
|
||||
== Email Protocols
|
||||
indexterm:[email,protocols]
|
||||
Today, email is delivered using a client/server architecture. An email message is created using a mail client program. This program then sends the message to a server. The server then forwards the message to the recipient's email server, where the message is then supplied to the recipient's email client.
|
||||
|
||||
|
|
@ -17,12 +17,12 @@ To enable this process, a variety of standard network protocols allow different
|
|||
The following protocols discussed are the most commonly used in the transfer of email.
|
||||
|
||||
[[s2-email-protocols-send]]
|
||||
===== Mail Transport Protocols
|
||||
=== Mail Transport Protocols
|
||||
|
||||
Mail delivery from a client application to the server, and from an originating server to the destination server, is handled by the _Simple Mail Transfer Protocol_ (_SMTP_).
|
||||
|
||||
[[s3-email-protocols-smtp]]
|
||||
====== SMTP
|
||||
==== SMTP
|
||||
indexterm:[email,protocols,SMTP]
|
||||
The primary purpose of SMTP is to transfer email between mail servers. However, it is critical for email clients as well. To send email, the client sends the message to an outgoing mail server, which in turn contacts the destination mail server for delivery. For this reason, it is necessary to specify an SMTP server when configuring an email client.
|
||||
|
||||
|
|
@ -33,12 +33,12 @@ One important point to make about the SMTP protocol is that it does not require
|
|||
{MAJOROS} provides the Postfix and Sendmail SMTP programs.
|
||||
|
||||
[[s2-email-protocols-client]]
|
||||
===== Mail Access Protocols
|
||||
=== Mail Access Protocols
|
||||
|
||||
There are two primary protocols used by email client applications to retrieve email from mail servers: the _Post Office Protocol_ (_POP_) and the _Internet Message Access Protocol_ (_IMAP_).
|
||||
|
||||
[[s3-email-protocols-pop]]
|
||||
====== POP
|
||||
==== POP
|
||||
indexterm:[email,protocols,POP]
|
||||
The default POP server under {MAJOROS} is [application]*Dovecot* and is provided by the [package]*dovecot* package.
|
||||
|
||||
|
|
@ -76,7 +76,7 @@ There are, however, a variety of lesser-used `POP` protocol variants:
|
|||
For added security, it is possible to use _Secure Socket Layer_ (_SSL_) encryption for client authentication and data transfer sessions. This can be enabled by using the [command]#pop3s# service, or by using the [command]#stunnel# application. For more information on securing email communication, see xref:Mail_Servers.adoc#s2-email-security[Securing Communication].
|
||||
|
||||
[[s3-email-protocols-imap]]
|
||||
====== IMAP
|
||||
==== IMAP
|
||||
indexterm:[email,protocols,IMAP]
|
||||
The default `IMAP` server under {MAJOROS} is [application]*Dovecot* and is provided by the [package]*dovecot* package. See xref:Mail_Servers.adoc#s3-email-protocols-pop[POP] for information on how to install [application]*Dovecot*.
|
||||
|
||||
|
|
@ -93,7 +93,7 @@ For added security, it is possible to use `SSL` encryption for client authentica
|
|||
Other free, as well as commercial, IMAP clients and servers are available, many of which extend the IMAP protocol and provide additional functionality.
|
||||
|
||||
[[s3-mail-server-dovecot]]
|
||||
====== Dovecot
|
||||
==== Dovecot
|
||||
indexterm:[email,mail server,Dovecot]
|
||||
The [command]#imap-login# and [command]#pop3-login# processes which implement the `IMAP` and `POP3` protocols are spawned by the master `dovecot` daemon included in the [package]*dovecot* package. The use of `IMAP` and `POP` is configured through the `/etc/dovecot/dovecot.conf` configuration file; by default [command]#dovecot# runs `IMAP` and `POP3` together with their secure versions using `SSL`. To configure [command]#dovecot# to use `POP`, complete the following steps:
|
||||
|
||||
|
|
@ -147,12 +147,12 @@ To configure `SSL` on [command]#dovecot#:
|
|||
More details on [command]#dovecot# can be found online at link:++http://www.dovecot.org++[http://www.dovecot.org].
|
||||
|
||||
[[s1-email-types]]
|
||||
==== Email Program Classifications
|
||||
== Email Program Classifications
|
||||
indexterm:[email,program classifications]
|
||||
In general, all email applications fall into at least one of three classifications. Each classification plays a specific role in the process of moving and managing email messages. While most users are only aware of the specific email program they use to receive and send messages, each one is important for ensuring that email arrives at the correct destination.
|
||||
|
||||
[[s2-email-types-mta]]
|
||||
===== Mail Transport Agent
|
||||
=== Mail Transport Agent
|
||||
indexterm:[email,types,Mail Transport Agent]indexterm:[Mail Transport Agent,email]indexterm:[MTA,Mail Transport Agent]
|
||||
A _Mail Transport Agent_ (_MTA_) transports email messages between hosts using `SMTP`. A message may involve several MTAs as it moves to its intended destination.
|
||||
|
||||
|
|
@ -165,21 +165,21 @@ Since {MAJOROS} offers two MTAs, _Postfix_ and _Sendmail_, email client programs
|
|||
For more information on Postfix, Sendmail, and Fetchmail, see xref:Mail_Servers.adoc#s1-email-mta[Mail Transport Agents].
|
||||
|
||||
[[s2-email-types-mda]]
|
||||
===== Mail Delivery Agent
|
||||
=== Mail Delivery Agent
|
||||
indexterm:[email,types,Mail Delivery Agent]indexterm:[Mail Delivery Agent,email]indexterm:[MDA,Mail Delivery Agent]
|
||||
A _Mail Delivery Agent_ (_MDA_) is invoked by the MTA to file incoming email in the proper user's mailbox. In many cases, the MDA is actually a _Local Delivery Agent_ (_LDA_), such as [command]#mail# or Procmail.
|
||||
|
||||
Any program that actually handles a message for delivery to the point where it can be read by an email client application can be considered an MDA. For this reason, some MTAs (such as Sendmail and Postfix) can fill the role of an MDA when they append new email messages to a local user's mail spool file. In general, MDAs do not transport messages between systems nor do they provide a user interface; MDAs distribute and sort messages on the local machine for an email client application to access.
|
||||
|
||||
[[s2-email-types-mua]]
|
||||
===== Mail User Agent
|
||||
=== Mail User Agent
|
||||
indexterm:[email,types,Mail User Agent]indexterm:[Mail User Agent,email]indexterm:[MUA,Mail User Agent]
|
||||
A _Mail User Agent_ (_MUA_) is synonymous with an email client application. An MUA is a program that, at a minimum, allows a user to read and compose email messages. Many MUAs are capable of retrieving messages via the `POP` or `IMAP` protocols, setting up mailboxes to store messages, and sending outbound messages to an MTA.
|
||||
|
||||
MUAs may be graphical, such as [application]*Evolution*, or have simple text-based interfaces, such as [application]*Mutt*.
|
||||
|
||||
[[s1-email-mta]]
|
||||
==== Mail Transport Agents
|
||||
== Mail Transport Agents
|
||||
|
||||
{MAJOROS} offers two primary MTAs: Postfix and Sendmail. Postfix is configured as the default MTA and Sendmail is considered deprecated. If required to switch the default MTA to Sendmail, you can either uninstall Postfix or use the following command as `root` to switch to Sendmail:
|
||||
|
||||
|
|
@ -205,7 +205,7 @@ Similarly, to disable the service, type the following at a shell prompt:
|
|||
For more information on how to manage system services in {MAJOROSVER}, see xref:../infrastructure-services/Services_and_Daemons.adoc#ch-Services_and_Daemons[Services and Daemons].
|
||||
|
||||
[[s2-email-mta-postfix]]
|
||||
===== Postfix
|
||||
=== Postfix
|
||||
indexterm:[email,Postfix]indexterm:[Postfix]
|
||||
Originally developed at IBM by security expert and programmer Wietse Venema, Postfix is a Sendmail-compatible MTA that is designed to be secure, fast, and easy to configure.
|
||||
|
||||
|
|
@ -216,7 +216,7 @@ Configuring Postfix to accept network connections from hosts other than the loca
|
|||
The configuration files for Postfix are human readable and support upward of 250 directives. Unlike Sendmail, no macro processing is required for changes to take effect and the majority of the most commonly used options are described in the heavily commented files.
|
||||
|
||||
[[s3-email-mta-postfix-default]]
|
||||
====== The Default Postfix Installation
|
||||
==== The Default Postfix Installation
|
||||
indexterm:[Postfix,default installation]
|
||||
The Postfix executable is `postfix`. This daemon launches all related processes needed to handle mail delivery.
|
||||
|
||||
|
|
@ -248,7 +248,7 @@ Restart the `postfix` service after changing any options in the configuration fi
|
|||
----
|
||||
|
||||
[[s3-email-mta-postfix-conf]]
|
||||
====== Basic Postfix Configuration
|
||||
==== Basic Postfix Configuration
|
||||
|
||||
By default, Postfix does not accept network connections from any host other than the local host. Perform the following steps as `root` to enable mail delivery for other hosts on the network:
|
||||
|
||||
|
|
@ -275,7 +275,7 @@ Once these steps are complete, the host accepts outside emails for delivery.
|
|||
Postfix has a large assortment of configuration options. One of the best ways to learn how to configure Postfix is to read the comments within the `/etc/postfix/main.cf` configuration file. Additional resources including information about Postfix configuration, SpamAssassin integration, or detailed descriptions of the `/etc/postfix/main.cf` parameters are available online at link:++http://www.postfix.org/++[http://www.postfix.org/].
|
||||
|
||||
[[using-postfix-with-ldap]]
|
||||
====== Using Postfix with LDAP
|
||||
==== Using Postfix with LDAP
|
||||
|
||||
Postfix can use an `LDAP` directory as a source for various lookup tables (e.g.: `aliases`, `virtual`, `canonical`, etc.). This allows `LDAP` to store hierarchical user information and Postfix to only be given the result of `LDAP` queries when needed. By not storing this information locally, administrators can easily maintain it.
|
||||
|
||||
|
|
@ -309,12 +309,12 @@ The `/etc/postfix/ldap-aliases.cf` file can specify various parameters, includin
|
|||
For more information on `LDAP`, see xref:Directory_Servers.adoc#s1-OpenLDAP[OpenLDAP].
|
||||
|
||||
[[s2-email-mta-sendmail]]
|
||||
===== Sendmail
|
||||
=== Sendmail
|
||||
indexterm:[email,Sendmail]indexterm:[Sendmail]
|
||||
Sendmail's core purpose, like other MTAs, is to safely transfer email among hosts, usually using the `SMTP` protocol. Note that Sendmail is considered deprecated and users are encouraged to use Postfix when possible. See xref:Mail_Servers.adoc#s2-email-mta-postfix[Postfix] for more information.
|
||||
|
||||
[[s3-email-mta-sendmail-purpose]]
|
||||
====== Purpose and Limitations
|
||||
==== Purpose and Limitations
|
||||
indexterm:[Sendmail,purpose]indexterm:[Sendmail,limitations]
|
||||
It is important to be aware of what Sendmail is and what it can do, as opposed to what it is not. In these days of monolithic applications that fulfill multiple roles, Sendmail may seem like the only application needed to run an email server within an organization. Technically, this is true, as Sendmail can spool mail to each users' directory and deliver outbound mail for users. However, most users actually require much more than simple email delivery. Users usually want to interact with their email using an MUA, that uses `POP` or `IMAP`, to download their messages to their local machine. Or, they may prefer a Web interface to gain access to their mailbox. These other applications can work in conjunction with Sendmail, but they actually exist for different reasons and can operate separately from one another.
|
||||
|
||||
|
|
@ -323,7 +323,7 @@ It is beyond the scope of this section to go into all that Sendmail should or co
|
|||
This section reviews the files installed with Sendmail by default and reviews basic configuration changes, including how to stop unwanted email (spam) and how to extend Sendmail with the _Lightweight Directory Access Protocol (LDAP)_.
|
||||
|
||||
[[s3-email-mta-sendmail-default]]
|
||||
====== The Default Sendmail Installation
|
||||
==== The Default Sendmail Installation
|
||||
indexterm:[Sendmail,default installation]
|
||||
In order to use Sendmail, first ensure the [package]*sendmail* package is installed on your system by running, as `root`:
|
||||
|
||||
|
|
@ -423,7 +423,7 @@ To finalize the change, the `virtusertable.db` file must be updated:
|
|||
Using the [option]`all` option will result in the `virtusertable.db` and `access.db` being updated at the same time.
|
||||
|
||||
[[s3-email-mta-sendmail-changes]]
|
||||
====== Common Sendmail Configuration Changes
|
||||
==== Common Sendmail Configuration Changes
|
||||
indexterm:[Sendmail,common configuration changes]indexterm:[Sendmail,with UUCP]
|
||||
When altering the Sendmail configuration file, it is best not to edit an existing file, but to generate an entirely new `/etc/mail/sendmail.cf` file.
|
||||
|
||||
|
|
@ -460,7 +460,7 @@ The default configuration in {MAJOROS} works for most `SMTP`-only sites. However
|
|||
Consult the `/usr/share/sendmail-cf/README` file before editing any files in the directories under the `/usr/share/sendmail-cf/` directory, as they can affect the future configuration of the `/etc/mail/sendmail.cf` file.
|
||||
|
||||
[[s3-email-sendmail-changes-masquerading]]
|
||||
====== Masquerading
|
||||
==== Masquerading
|
||||
indexterm:[Sendmail,aliases]indexterm:[Sendmail,masquerading]
|
||||
One common Sendmail configuration is to have a single machine act as a mail gateway for all machines on the network. For example, a company may want to have a machine called `mail.example.com` that handles all of their email and assigns a consistent return address to all outgoing mail.
|
||||
|
||||
|
|
@ -481,7 +481,7 @@ MASQUERADE_AS(example.com)dnl
|
|||
After generating a new `sendmail.cf` file using the [command]#m4# macro processor, this configuration makes all mail from inside the network appear as if it were sent from `example.com`.
|
||||
|
||||
[[s3-email-sendmail-stopping-spam]]
|
||||
====== Stopping Spam
|
||||
==== Stopping Spam
|
||||
indexterm:[Sendmail,spam]
|
||||
Email spam can be defined as unnecessary and unwanted email received by a user who never requested the communication. It is a disruptive, costly, and widespread abuse of Internet communication standards.
|
||||
|
||||
|
|
@ -517,7 +517,7 @@ The above examples only represent a small part of what Sendmail can do in terms
|
|||
Since Sendmail calls the Procmail MDA when delivering mail, it is also possible to use a spam filtering program, such as SpamAssassin, to identify and file spam for users. See xref:Mail_Servers.adoc#s3-email-mda-spam[Spam Filters] for more information about using SpamAssassin.
|
||||
|
||||
[[s3-email-mta-sendmail-ldap]]
|
||||
====== Using Sendmail with LDAP
|
||||
==== Using Sendmail with LDAP
|
||||
indexterm:[Sendmail,LDAP and]
|
||||
Using `LDAP` is a very quick and powerful way to find specific information about a particular user from a much larger group. For example, an `LDAP` server can be used to look up a particular email address from a common corporate directory by the user's last name. In this kind of implementation, `LDAP` is largely separate from Sendmail, with `LDAP` storing the hierarchical user information and Sendmail only being given the result of `LDAP` queries in pre-addressed email messages.
|
||||
|
||||
|
|
@ -546,7 +546,7 @@ Next, recreate the `/etc/mail/sendmail.cf` file by running the [command]#m4# mac
|
|||
For more information on `LDAP`, see xref:Directory_Servers.adoc#s1-OpenLDAP[OpenLDAP].
|
||||
|
||||
[[s2-email-mta-fetchmail]]
|
||||
===== Fetchmail
|
||||
=== Fetchmail
|
||||
indexterm:[email,Fetchmail]indexterm:[Fetchmail]
|
||||
Fetchmail is an MTA which retrieves email from remote servers and delivers it to the local MTA. Many users appreciate the ability to separate the process of downloading their messages located on a remote server from the process of reading and organizing their email in an MUA. Designed with the needs of dial-up users in mind, Fetchmail connects and quickly downloads all of the email messages to the mail spool file using any number of protocols, including `POP3` and `IMAP`. It can even forward email messages to an `SMTP` server, if necessary.
|
||||
|
||||
|
|
@ -570,7 +570,7 @@ Fetchmail is configured for each user through the use of a `.fetchmailrc` file i
|
|||
Using preferences in the `.fetchmailrc` file, Fetchmail checks for email on a remote server and downloads it. It then delivers it to port 25 on the local machine, using the local MTA to place the email in the correct user's spool file. If Procmail is available, it is launched to filter the email and place it in a mailbox so that it can be read by an MUA.
|
||||
|
||||
[[s3-email-mda-fetchmail-configuration]]
|
||||
====== Fetchmail Configuration Options
|
||||
==== Fetchmail Configuration Options
|
||||
indexterm:[Fetchmail,configuration options]indexterm:[.fetchmailrc]
|
||||
Although it is possible to pass all necessary options on the command line to check for email on a remote server when executing Fetchmail, using a `.fetchmailrc` file is much easier. Place any desired configuration options in the `.fetchmailrc` file for those options to be used each time the [command]#fetchmail# command is issued. It is possible to override these at the time Fetchmail is run by specifying that option on the command line.
|
||||
|
||||
|
|
@ -614,7 +614,7 @@ Users are not required to place their password in the `.fetchmailrc` file. Omitt
|
|||
Fetchmail has numerous global, server, and local options. Many of these options are rarely used or only apply to very specific situations. The `fetchmail` man page explains each option in detail, but the most common ones are listed in the following three sections.
|
||||
|
||||
[[s3-email-mda-fetchmail-configuration-global]]
|
||||
====== Global Options
|
||||
==== Global Options
|
||||
indexterm:[Fetchmail,configuration options,global options]indexterm:[ch-email .fetchmailrc,global options]
|
||||
Each global option should be placed on a single line after a [command]#set# action.
|
||||
|
||||
|
|
@ -625,7 +625,7 @@ Each global option should be placed on a single line after a [command]#set# acti
|
|||
* [command]#syslog# — Specifies the log file for errors and status messages. By default, this is `/var/log/maillog`.
|
||||
|
||||
[[s3-email-mda-fetchmail-configuration-server]]
|
||||
====== Server Options
|
||||
==== Server Options
|
||||
indexterm:[Fetchmail,configuration options,server options]indexterm:[.fetchmailrc,server options]
|
||||
Server options must be placed on their own line in `.fetchmailrc` after a [command]#poll# or [command]#skip# action.
|
||||
|
||||
|
|
@ -640,7 +640,7 @@ Server options must be placed on their own line in `.fetchmailrc` after a [comma
|
|||
* [command]#timeout _seconds_pass:attributes[{blank}]# — Replace _seconds_ with the number of seconds of server inactivity after which Fetchmail gives up on a connection attempt. If this value is not set, a default of [command]#300# seconds is used.
|
||||
|
||||
[[s3-email-fetchmail-configuration-user]]
|
||||
====== User Options
|
||||
==== User Options
|
||||
indexterm:[Fetchmail,configuration options,user options]indexterm:[.fetchmailrc,user options]
|
||||
User options may be placed on their own lines beneath a server option or on the same line as the server option. In either case, the defined options must follow the [command]#user# option (defined below).
|
||||
|
||||
|
|
@ -663,14 +663,14 @@ User options may be placed on their own lines beneath a server option or on the
|
|||
* [command]#user "pass:attributes[{blank}]_username_pass:attributes[{blank}]"# — Replace _username_ with the username used by Fetchmail to retrieve messages. *This option must precede all other user options.*
|
||||
|
||||
[[s3-email-mda-fetchmail-commands]]
|
||||
====== Fetchmail Command Options
|
||||
==== Fetchmail Command Options
|
||||
indexterm:[Fetchmail,command options]
|
||||
Most Fetchmail options used on the command line when executing the [command]#fetchmail# command mirror the `.fetchmailrc` configuration options. In this way, Fetchmail may be used with or without a configuration file. These options are not used on the command line by most users because it is easier to leave them in the `.fetchmailrc` file.
|
||||
|
||||
There may be times when it is desirable to run the [command]#fetchmail# command with other options for a particular purpose. It is possible to issue command options to temporarily override a `.fetchmailrc` setting that is causing an error, as any options specified at the command line override configuration file options.
|
||||
|
||||
[[s3-email-mda-fetchmail-commands-info]]
|
||||
====== Informational or Debugging Options
|
||||
==== Informational or Debugging Options
|
||||
indexterm:[Fetchmail,command options,informational]
|
||||
Certain options used after the [command]#fetchmail# command can supply important information.
|
||||
|
||||
|
|
@ -683,7 +683,7 @@ Certain options used after the [command]#fetchmail# command can supply important
|
|||
* [command]#-V# — Displays detailed version information, lists its global options, and shows settings to be used with each user, including the email protocol and authentication method. No email is retrieved for any users when using this option.
|
||||
|
||||
[[s3-email-mda-fetchmail-commands-special]]
|
||||
====== Special Options
|
||||
==== Special Options
|
||||
indexterm:[Fetchmail,command options,special]
|
||||
These options are occasionally useful for overriding defaults often found in the `.fetchmailrc` file.
|
||||
|
||||
|
|
@ -698,7 +698,7 @@ These options are occasionally useful for overriding defaults often found in the
|
|||
More commands and `.fetchmailrc` options can be found in the [command]#fetchmail# man page.
|
||||
|
||||
[[s2-email-switchmail]]
|
||||
===== Mail Transport Agent (MTA) Configuration
|
||||
=== Mail Transport Agent (MTA) Configuration
|
||||
indexterm:[Mail Transport Agent,MTA]indexterm:[MTA,setting default]indexterm:[MTA,switching with Mail Transport Agent Switcher]indexterm:[Mail Transport Agent Switcher]indexterm:[Mail User Agent]indexterm:[MUA]
|
||||
A _Mail Transport Agent_ (MTA) is essential for sending email. A _Mail User Agent_ (MUA) such as [application]*Evolution*, [application]*Thunderbird*, and [application]*Mutt*, is used to read and compose email. When a user sends an email from an MUA, the message is handed off to the MTA, which sends the message through a series of MTAs until it reaches its destination.
|
||||
|
||||
|
|
@ -707,7 +707,7 @@ indexterm:[sendmail]indexterm:[postfix]
|
|||
{MAJOROSVER} provides two MTAs: Postfix and Sendmail. If both are installed, Postfix is the default MTA. Note that Sendmail is considered deprecated in MAJOROS;.
|
||||
|
||||
[[s1-email-mda]]
|
||||
==== Mail Delivery Agents
|
||||
== Mail Delivery Agents
|
||||
|
||||
{MAJOROS} includes two primary MDAs, Procmail and [command]#mail#. Both of the applications are considered LDAs and both move email from the MTA's spool file into the user's mailbox. However, Procmail provides a robust filtering system.
|
||||
|
||||
|
|
@ -724,7 +724,7 @@ Whether Procmail acts upon an email message depends upon whether the message mat
|
|||
When Procmail starts, it reads the email message and separates the body from the header information. Next, Procmail looks for a `/etc/procmailrc` file and `rc` files in the `/etc/procmailrcs` directory for default, system-wide, Procmail environmental variables and recipes. Procmail then searches for a `.procmailrc` file in the user's home directory. Many users also create additional `rc` files for Procmail that are referred to within the `.procmailrc` file in their home directory.
|
||||
|
||||
[[s2-email-procmail-configuration]]
|
||||
===== Procmail Configuration
|
||||
=== Procmail Configuration
|
||||
indexterm:[Procmail,configuration]indexterm:[.procmailrc]
|
||||
The Procmail configuration file contains important environmental variables. These variables specify things such as which messages to sort and what to do with the messages that do not match any recipes.
|
||||
|
||||
|
|
@ -779,7 +779,7 @@ Other important environmental variables are pulled from the shell, such as [comm
|
|||
A comprehensive explanation of all environments variables, and their default values, is available in the `procmailrc` man page.
|
||||
|
||||
[[s2-email-procmail-recipes]]
|
||||
===== Procmail Recipes
|
||||
=== Procmail Recipes
|
||||
indexterm:[Procmail,recipes]
|
||||
New users often find the construction of recipes the most difficult part of learning to use Procmail. This difficulty is often attributed to recipes matching messages by using _regular expressions_ which are used to specify qualifications for string matching. However, regular expressions are not very difficult to construct and even less difficult to understand when read. Additionally, the consistency of the way Procmail recipes are written, regardless of regular expressions, makes it easy to learn by example. To see example Procmail recipes, see xref:Mail_Servers.adoc#s3-email-procmail-recipes-examples[Recipe Examples].
|
||||
|
||||
|
|
@ -802,7 +802,7 @@ A recipe can contain several conditions to match against the message. If it has
|
|||
The [command]#pass:attributes[{blank}]_action-to-perform_pass:attributes[{blank}]# argument specifies the action taken when the message matches one of the conditions. There can only be one action per recipe. In many cases, the name of a mailbox is used here to direct matching messages into that file, effectively sorting the email. Special action characters may also be used before the action is specified. See xref:Mail_Servers.adoc#s3-email-procmail-recipes-special[Special Conditions and Actions] for more information.
|
||||
|
||||
[[s2-email-procmail-recipes-delivering]]
|
||||
====== Delivering vs. Non-Delivering Recipes
|
||||
==== Delivering vs. Non-Delivering Recipes
|
||||
indexterm:[Procmail,recipes,delivering]indexterm:[Procmail,recipes,non-delivering]
|
||||
The action used if the recipe matches a particular message determines whether it is considered a _delivering_ or _non-delivering_ recipe. A delivering recipe contains an action that writes the message to a file, sends the message to another program, or forwards the message to another email address. A non-delivering recipe covers any other actions, such as a _nesting block_. A nesting block is a set of actions, contained in braces [command]#{#
|
||||
[command]#}#, that are performed on messages which match the recipe's conditions. Nesting blocks can be nested inside one another, providing greater control for identifying and performing actions on messages.
|
||||
|
|
@ -810,7 +810,7 @@ The action used if the recipe matches a particular message determines whether it
|
|||
When messages match a delivering recipe, Procmail performs the specified action and stops comparing the message against any other recipes. Messages that match non-delivering recipes continue to be compared against other recipes.
|
||||
|
||||
[[s3-email-procmail-recipes-flags]]
|
||||
====== Flags
|
||||
==== Flags
|
||||
indexterm:[Procmail,recipes,flags]
|
||||
Flags are essential to determine how or if a recipe's conditions are compared to a message. The [application]*egrep* utility is used internally for matching of the conditions. The following flags are commonly used:
|
||||
|
||||
|
|
@ -843,14 +843,14 @@ Flags are essential to determine how or if a recipe's conditions are compared to
|
|||
For a detailed list of additional flags, see the `procmailrc` man page.
|
||||
|
||||
[[s3-email-procmail-recipes-lockfile]]
|
||||
====== Specifying a Local Lockfile
|
||||
==== Specifying a Local Lockfile
|
||||
indexterm:[Procmail,recipes,local lockfiles]
|
||||
Lockfiles are very useful with Procmail to ensure that more than one process does not try to alter a message simultaneously. Specify a local lockfile by placing a colon ([command]#:#) after any flags on a recipe's first line. This creates a local lockfile based on the destination file name plus whatever has been set in the [command]#LOCKEXT# global environment variable.
|
||||
|
||||
Alternatively, specify the name of the local lockfile to be used with this recipe after the colon.
|
||||
|
||||
[[s3-email-procmail-recipes-special]]
|
||||
====== Special Conditions and Actions
|
||||
==== Special Conditions and Actions
|
||||
indexterm:[Procmail,recipes,special conditions]indexterm:[Procmail,recipes,special actions]
|
||||
Special characters used before Procmail recipe conditions and actions change the way they are interpreted.
|
||||
|
||||
|
|
@ -875,7 +875,7 @@ The following characters are used to perform special actions:
|
|||
If no special character is used at the beginning of the action line, Procmail assumes that the action line is specifying the mailbox in which to write the message.
|
||||
|
||||
[[s3-email-procmail-recipes-examples]]
|
||||
====== Recipe Examples
|
||||
==== Recipe Examples
|
||||
indexterm:[Procmail,recipes,examples]
|
||||
Procmail is an extremely flexible program, but as a result of this flexibility, composing Procmail recipes from scratch can be difficult for new users.
|
||||
|
||||
|
|
@ -928,7 +928,7 @@ Any messages sent from the `tux-lug@domain.com` mailing list are placed in the `
|
|||
Consult the many Procmail online resources available in xref:Mail_Servers.adoc#s1-email-additional-resources[Additional Resources] for more detailed and powerful recipes.
|
||||
|
||||
[[s3-email-mda-spam]]
|
||||
====== Spam Filters
|
||||
==== Spam Filters
|
||||
indexterm:[Procmail,recipes,SpamAssassin]indexterm:[SpamAssassin,using with Procmail]indexterm:[email,spam,filtering out]
|
||||
Because it is called by Sendmail, Postfix, and Fetchmail upon receiving new emails, Procmail can be used as a powerful tool for combating spam.
|
||||
|
||||
|
|
@ -1000,28 +1000,28 @@ INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc
|
|||
----
|
||||
|
||||
[[s1-email-mua]]
|
||||
==== Mail User Agents
|
||||
== Mail User Agents
|
||||
|
||||
{MAJOROS} offers a variety of email programs, both, graphical email client programs, such as [application]*Evolution*, and text-based email programs such as [command]#mutt#.
|
||||
|
||||
The remainder of this section focuses on securing communication between a client and a server.
|
||||
|
||||
[[s2-email-security]]
|
||||
===== Securing Communication
|
||||
=== Securing Communication
|
||||
|
||||
Popular MUAs included with {MAJOROS}, such as [application]*Evolution* and [application]*Mutt* offer SSL-encrypted email sessions.
|
||||
indexterm:[email,security]
|
||||
Like any other service that flows over a network unencrypted, important email information, such as user names, passwords, and entire messages, may be intercepted and viewed by users on the network. Additionally, since the standard `POP` and `IMAP` protocols pass authentication information unencrypted, it is possible for an attacker to gain access to user accounts by collecting user names and passwords as they are passed over the network.
|
||||
|
||||
[[s3-email-security-clients]]
|
||||
====== Secure Email Clients
|
||||
==== Secure Email Clients
|
||||
indexterm:[email,security,clients]
|
||||
Most Linux MUAs designed to check email on remote servers support SSL encryption. To use SSL when retrieving email, it must be enabled on both the email client and the server.
|
||||
|
||||
SSL is easy to enable on the client-side, often done with the click of a button in the MUA's configuration window or via an option in the MUA's configuration file. Secure `IMAP` and `POP` have known port numbers (993 and 995, respectively) that the MUA uses to authenticate and download messages.
|
||||
|
||||
[[s3-email-security-servers]]
|
||||
====== Securing Email Client Communications
|
||||
==== Securing Email Client Communications
|
||||
indexterm:[email,security,servers]indexterm:[stunnel]
|
||||
Offering SSL encryption to `IMAP` and `POP` users on the email server is a simple matter.
|
||||
|
||||
|
|
@ -1104,12 +1104,12 @@ Once you start [command]#stunnel# with the created configuration file using the
|
|||
For more information on [command]#stunnel#, see the `stunnel(8)` man page or the documents in the `/usr/share/doc/stunnel/` directory.
|
||||
|
||||
[[s1-email-additional-resources]]
|
||||
==== Additional Resources
|
||||
== Additional Resources
|
||||
indexterm:[email,additional resources]indexterm:[Sendmail,additional resources]indexterm:[Procmail,additional resources]indexterm:[Fetchmail,additional resources]
|
||||
The following is a list of additional documentation about email applications.
|
||||
|
||||
[[s2-email-installed-docs]]
|
||||
===== Installed Documentation
|
||||
=== Installed Documentation
|
||||
indexterm:[email,additional resources,installed documentation]
|
||||
|
||||
* Information on configuring Sendmail is included with the [package]*sendmail* and [package]*sendmail-cf* packages.
|
||||
|
|
@ -1137,7 +1137,7 @@ When learning how Procmail works and creating new recipes, the following Procmai
|
|||
** `/usr/share/doc/spamassassin/` — Contains a large amount of information pertaining to SpamAssassin.
|
||||
|
||||
[[s2-email-useful-websites]]
|
||||
===== Useful Websites
|
||||
=== Useful Websites
|
||||
indexterm:[email,additional resources,useful websites]
|
||||
|
||||
* link:++https://www.proofpoint.com/us/sendmail-open-source++[Proofpoint Open Source Sendmail] — Provides link to sourcecode for sendmail open source, current GPG keys, and contact email addresses.
|
||||
|
|
@ -1149,7 +1149,7 @@ indexterm:[email,additional resources,useful websites]
|
|||
* link:++http://spamassassin.apache.org/++[http://spamassassin.apache.org/] — The official site of the SpamAssassin project.
|
||||
|
||||
[[s2-email-related-books]]
|
||||
===== Related Books
|
||||
=== Related Books
|
||||
indexterm:[email,additional resources,related books]
|
||||
|
||||
* [citetitle]_Sendmail Milters: A Guide for Fighting Spam_ by Bryan Costales and Marcia Flynt; Addison-Wesley — A good Sendmail guide that can help you customize your mail filters.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
|
||||
[[s1-OpenLDAP]]
|
||||
==== OpenLDAP
|
||||
== OpenLDAP
|
||||
indexterm:[directory server,OpenLDAP]indexterm:[LDAP,OpenLDAP]indexterm:[X.500,OpenLDAP]indexterm:[X.500 Lite,OpenLDAP]
|
||||
`LDAP` (Lightweight Directory Access Protocol) is a set of open protocols used to access centrally stored information over a network. It is based on the `X.500` standard for directory sharing, but is less complex and resource-intensive. For this reason, LDAP is sometimes referred to as "X.500 Lite".
|
||||
|
||||
|
|
@ -11,7 +11,7 @@ LDAP is commonly used for centrally managed users and groups, user authenticatio
|
|||
This section covers the installation and configuration of [application]*OpenLDAP 2.4*, an open source implementation of the LDAPv2 and LDAPv3 protocols.
|
||||
|
||||
[[s2-ldap-introduction]]
|
||||
===== Introduction to LDAP
|
||||
=== Introduction to LDAP
|
||||
|
||||
Using a client-server architecture, LDAP provides a reliable means to create a central information directory accessible from the network. When a client attempts to modify information within this directory, the server verifies the user has permission to make the change, and then adds or updates the entry as requested. To ensure the communication is secure, the _Transport Layer Security_ (*TLS*) cryptographic protocol can be used to prevent an attacker from intercepting the transmission.
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ The OpenLDAP suite in {MAJOROSVER} no longer uses OpenSSL. Instead, it uses the
|
|||
The LDAP server supports several database systems, which gives administrators the flexibility to choose the best suited solution for the type of information they are planning to serve. Because of a well-defined client _Application Programming Interface_ (*API*), the number of applications able to communicate with an LDAP server is numerous, and increasing in both quantity and quality.
|
||||
|
||||
[[s3-ldap-terminology]]
|
||||
====== LDAP Terminology
|
||||
==== LDAP Terminology
|
||||
|
||||
The following is a list of LDAP-specific terms that are used within this chapter:
|
||||
|
||||
|
|
@ -51,7 +51,7 @@ pass:quotes[_attribute_type_]: pass:quotes[_attribute_value_]…
|
|||
The optional _id_ is a number determined by the application that is used to edit the entry. Each entry can contain as many _attribute_type_ and _attribute_value_ pairs as needed, as long as they are all defined in a corresponding schema file. A blank line indicates the end of an entry.
|
||||
|
||||
[[s3-ldap-features]]
|
||||
====== OpenLDAP Features
|
||||
==== OpenLDAP Features
|
||||
indexterm:[OpenLDAP,features]
|
||||
OpenLDAP suite provides a number of important features:
|
||||
|
||||
|
|
@ -68,7 +68,7 @@ OpenLDAP suite provides a number of important features:
|
|||
* *Enhanced Standalone LDAP Server* — This includes an updated access control system, thread pooling, better tools, and much more.
|
||||
|
||||
[[s3-ldap-setup]]
|
||||
====== OpenLDAP Server Setup
|
||||
==== OpenLDAP Server Setup
|
||||
indexterm:[OpenLDAP,configuration,overview]
|
||||
The typical steps to set up an LDAP server on {MAJOROS} are as follows:
|
||||
|
||||
|
|
@ -83,7 +83,7 @@ The typical steps to set up an LDAP server on {MAJOROS} are as follows:
|
|||
. Use the [command]#ldapsearch# utility to verify that the `slapd` service is accessing the information correctly.
|
||||
|
||||
[[s2-ldap-installation]]
|
||||
===== Installing the OpenLDAP Suite
|
||||
=== Installing the OpenLDAP Suite
|
||||
indexterm:[OpenLDAP,installation]indexterm:[OpenLDAP,packages]
|
||||
The suite of OpenLDAP libraries and tools is provided by the following packages:
|
||||
|
||||
|
|
@ -128,7 +128,7 @@ For example, to perform the basic LDAP server installation, type the following a
|
|||
Note that you must have superuser privileges (that is, you must be logged in as `root`) to run this command. For more information on how to install new packages in {MAJOROS}, see xref:../package-management/DNF.adoc#sec-Installing[Installing Packages].
|
||||
|
||||
[[s3-ldap-packages-openldap-servers]]
|
||||
====== Overview of OpenLDAP Server Utilities
|
||||
==== Overview of OpenLDAP Server Utilities
|
||||
indexterm:[OpenLDAP,utilities]
|
||||
To perform administrative tasks, the [package]*openldap-servers* package installs the following utilities along with the `slapd` service:
|
||||
|
||||
|
|
@ -180,7 +180,7 @@ For more information on how to start, stop, restart, and check the current statu
|
|||
====
|
||||
|
||||
[[s3-ldap-packages-openldap-clients]]
|
||||
====== Overview of OpenLDAP Client Utilities
|
||||
==== Overview of OpenLDAP Client Utilities
|
||||
indexterm:[OpenLDAP,utilities]
|
||||
The [package]*openldap-clients* package installs the following utilities which can be used to add, modify, and delete entries in an LDAP directory:
|
||||
|
||||
|
|
@ -205,12 +205,12 @@ The [package]*openldap-clients* package installs the following utilities which c
|
|||
With the exception of [command]#ldapsearch#, each of these utilities is more easily used by referencing a file containing the changes to be made rather than typing a command for each entry to be changed within an LDAP directory. The format of such a file is outlined in the man page for each utility.
|
||||
|
||||
[[s3-ldap-packages-applications]]
|
||||
====== Overview of Common LDAP Client Applications
|
||||
==== Overview of Common LDAP Client Applications
|
||||
indexterm:[OpenLDAP,client applications]
|
||||
Although there are various graphical LDAP clients capable of creating and modifying directories on the server, none of them is included in {MAJOROS}. Popular applications that can access directories in a read-only mode include [application]*Mozilla Thunderbird*, [application]*Evolution*, or [application]*Ekiga*.
|
||||
|
||||
[[s2-ldap-configuration]]
|
||||
===== Configuring an OpenLDAP Server
|
||||
=== Configuring an OpenLDAP Server
|
||||
|
||||
By default, the OpenLDAP configuration is stored in the `/etc/openldap/` directory. The following table highlights the most important directories and files within this directory:
|
||||
|
||||
|
|
@ -244,7 +244,7 @@ An error in an LDIF file can render the `slapd` service unable to start. Because
|
|||
====
|
||||
|
||||
[[s3-ldap-configuration-global]]
|
||||
====== Changing the Global Configuration
|
||||
==== Changing the Global Configuration
|
||||
indexterm:[OpenLDAP,configuration,global]indexterm:[OpenLDAP,files,/etc/openldap/slapd.d/cn=config.ldif]
|
||||
Global configuration options for the LDAP server are stored in the `/etc/openldap/slapd.d/cn=config.ldif` file. The following directives are commonly used:
|
||||
|
||||
|
|
@ -432,7 +432,7 @@ olcWriteTimeout: 180
|
|||
====
|
||||
|
||||
[[s3-ldap-configuration-database]]
|
||||
====== Changing the Database-Specific Configuration
|
||||
==== Changing the Database-Specific Configuration
|
||||
indexterm:[OpenLDAP,configuration,database]indexterm:[OpenLDAP,files,/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif]
|
||||
By default, the OpenLDAP server uses Berkeley DB (BDB) as a database back end. The configuration for this database is stored in the `/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif` file. The following directives are commonly used in a database-specific configuration:
|
||||
|
||||
|
|
@ -525,12 +525,12 @@ olcSuffix: dc=example,dc=com
|
|||
====
|
||||
|
||||
[[s3-ldap-configuration-schema]]
|
||||
====== Extending Schema
|
||||
==== Extending Schema
|
||||
indexterm:[OpenLDAP,schema]indexterm:[OpenLDAP,directories,/etc/openldap/slapd.d/cn=config/cn=schema/]
|
||||
Since OpenLDAP 2.3, the `/etc/openldap/slapd.d/` directory also contains LDAP definitions that were previously located in `/etc/openldap/schema/`. It is possible to extend the schema used by OpenLDAP to support additional attribute types and object classes using the default schema files as a guide. However, this task is beyond the scope of this chapter. For more information on this topic, see link:++http://www.openldap.org/doc/admin/schema.html++[].
|
||||
|
||||
[[s3-establishing_a_secure_connection]]
|
||||
====== Establishing a Secure Connection
|
||||
==== Establishing a Secure Connection
|
||||
indexterm:[OpenLDAP,configuration,TLS]indexterm:[OpenLDAP,files,/etc/openldap/ldap.conf]indexterm:[OpenLDAP,files,/etc/openldap/slapd.d/cn=config.ldif]indexterm:[OpenLDAP,security]
|
||||
OpenLDAP clients and servers can be secured using the Transport Layer Security (TLS) framework. TLS is a cryptographic protocol designed to provide communication security over the network. As noted above, OpenLDAP suite in Fedora uses Mozilla NSS as the TLS implementation.
|
||||
|
||||
|
|
@ -693,7 +693,7 @@ TLS_KEY pass:quotes[_path_]
|
|||
Replace _path_ with a path to the client certificate file or with a name of the password file in the NSS database.
|
||||
|
||||
[[s3-setting_up_replication]]
|
||||
====== Setting Up Replication
|
||||
==== Setting Up Replication
|
||||
indexterm:[OpenLDAP,configuration,TLS]indexterm:[OpenLDAP,directories,/etc/openldap/slapd.d/]indexterm:[OpenLDAP,replication]
|
||||
Replication is the process of copying updates from one LDAP server (*provider*) to one or more other servers or clients (*consumers*). A provider replicates directory updates to consumers, the received updates can be further propagated by the consumer to other servers, so a consumer can also act simultaneously as a provider. Also, a consumer does not have to be an LDAP server, it may be just an LDAP client. In OpenLDAP, you can use several replication modes, most notable are *mirror* and *sync*. For more information on OpenLDAP replication modes, see the *OpenLDAP Software Administrator's Guide* installed with [package]*openldap-servers* package (see xref:Directory_Servers.adoc#bh-Installed_Documentation_OpenLDAP[Installed Documentation]).
|
||||
|
||||
|
|
@ -718,7 +718,7 @@ This option needs to be specified both on provider and consumers. Also a [option
|
|||
The sync replication mode requires a specific configuration on both the provider and the consumers. This configuration is thoroughly described in the *18.3.1. Syncrepl* section of the *OpenLDAP Software Administrator's Guide* (see xref:Directory_Servers.adoc#bh-Installed_Documentation_OpenLDAP[Installed Documentation]).
|
||||
|
||||
[[s3-loading_modules_or_backends]]
|
||||
====== Loading Modules and Backends
|
||||
==== Loading Modules and Backends
|
||||
indexterm:[OpenLDAP,configuration,TLS]indexterm:[OpenLDAP,directories,/etc/openldap/slapd.d/]indexterm:[OpenLDAP,modules]indexterm:[OpenLDAP,backends]
|
||||
You can enhance the `slapd` service with dynamically loaded modules. Support for these modules must be enabled with the [option]`--enable-modules` option when configuring `slapd`. Modules are stored in files with the *.la* extension:
|
||||
|
||||
|
|
@ -746,7 +746,7 @@ To load a module or a backend, use the following directive in `/etc/openldap/sla
|
|||
Here, _module_ stands either for a file containing the module, or a backend, that will be loaded.
|
||||
|
||||
[[s2-selinux-openldap]]
|
||||
===== SELinux Policy for Applications Using LDAP
|
||||
=== SELinux Policy for Applications Using LDAP
|
||||
|
||||
SELinux is an implementation of a mandatory access control mechanism in the Linux kernel. By default, SELinux prevents applications from accessing an OpenLDAP server. To enable authentication through LDAP, which is required by several applications, the `allow_ypbind` SELinux Boolean needs to be enabled. Certain applications also demand an enabled `authlogin_nsswitch_use_ldap` Boolean in this scenario. Execute the following commands to enable the aforementioned Booleans:
|
||||
|
||||
|
|
@ -763,12 +763,12 @@ SELinux is an implementation of a mandatory access control mechanism in the Linu
|
|||
The [option]`-P` option makes this setting persistent across system reboots. See the link:++https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/++[Red{nbsp}Hat Enterprise{nbsp}Linux{nbsp}7 SELinux User's and Administrator's Guide] for more detailed information about SELinux.
|
||||
|
||||
[[s2-ldap-running]]
|
||||
===== Running an OpenLDAP Server
|
||||
=== Running an OpenLDAP Server
|
||||
indexterm:[slapd,OpenLDAP]
|
||||
This section describes how to start, stop, restart, and check the current status of the [application]*Standalone LDAP Daemon*. For more information on how to manage system services in general, see xref:../infrastructure-services/Services_and_Daemons.adoc#ch-Services_and_Daemons[Services and Daemons].
|
||||
|
||||
[[s3-ldap-running-starting]]
|
||||
====== Starting the Service
|
||||
==== Starting the Service
|
||||
indexterm:[OpenLDAP,running]
|
||||
To start the `slapd` service in the current session, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -787,7 +787,7 @@ To configure the service to start automatically at the boot time, use the follow
|
|||
See xref:../infrastructure-services/Services_and_Daemons.adoc#ch-Services_and_Daemons[Services and Daemons] for more information on how to configure services in {MAJOROS}.
|
||||
|
||||
[[s3-ldap-running-stopping]]
|
||||
====== Stopping the Service
|
||||
==== Stopping the Service
|
||||
indexterm:[OpenLDAP,stopping]
|
||||
To stop the running `slapd` service in the current session, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -807,7 +807,7 @@ rm '/etc/systemd/system/multi-user.target.wants/slapd.service'
|
|||
See xref:../infrastructure-services/Services_and_Daemons.adoc#ch-Services_and_Daemons[Services and Daemons] for more information on how to configure services in {MAJOROS}.
|
||||
|
||||
[[s3-ldap-running-restarting]]
|
||||
====== Restarting the Service
|
||||
==== Restarting the Service
|
||||
indexterm:[OpenLDAP,restarting]
|
||||
To restart the running `slapd` service, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -819,7 +819,7 @@ To restart the running `slapd` service, type the following at a shell prompt as
|
|||
This stops the service and immediately starts it again. Use this command to reload the configuration.
|
||||
|
||||
[[s3-ldap-running-status]]
|
||||
====== Verifying the Service Status
|
||||
==== Verifying the Service Status
|
||||
indexterm:[OpenLDAP,checking status]
|
||||
To verify that the `slapd` service is running, type the following at a shell prompt:
|
||||
|
||||
|
|
@ -830,7 +830,7 @@ active
|
|||
----
|
||||
|
||||
[[s2-ldap-pam]]
|
||||
===== Configuring a System to Authenticate Using OpenLDAP
|
||||
=== Configuring a System to Authenticate Using OpenLDAP
|
||||
|
||||
In order to configure a system to authenticate using OpenLDAP, make sure that the appropriate packages are installed on both LDAP server and client machines. For information on how to set up the server, follow the instructions in xref:Directory_Servers.adoc#s2-ldap-installation[Installing the OpenLDAP Suite] and xref:Directory_Servers.adoc#s2-ldap-configuration[Configuring an OpenLDAP Server]. On a client, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -840,7 +840,7 @@ In order to configure a system to authenticate using OpenLDAP, make sure that th
|
|||
----
|
||||
|
||||
[[s3-ldap-migrationtools]]
|
||||
====== Migrating Old Authentication Information to LDAP Format
|
||||
==== Migrating Old Authentication Information to LDAP Format
|
||||
indexterm:[OpenLDAP,migrating authentication information]
|
||||
The [package]*migrationtools* package provides a set of shell and Perl scripts to help you migrate authentication information into an LDAP format. To install this package, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -886,7 +886,7 @@ To decide which script to run in order to migrate the user database, see xref:Di
|
|||
For more information on how to use these scripts, see the `README` and the `migration-tools.txt` files in the `/usr/share/doc/migrationtools/` directory.
|
||||
|
||||
[[s2-ldap-resources]]
|
||||
===== Additional Resources
|
||||
=== Additional Resources
|
||||
|
||||
The following resources offer additional information on the Lightweight Directory Access Protocol. Before configuring LDAP on your system, it is highly recommended that you review these resources, especially the [citetitle]_OpenLDAP Software Administrator's Guide_.
|
||||
|
||||
|
|
@ -949,7 +949,7 @@ link:++http://www.ldapman.org/articles/++[]:: A collection of articles that off
|
|||
link:++http://www.padl.com/++[]:: A website of developers of several useful LDAP tools.
|
||||
|
||||
[[s3-ldap-related-books]]
|
||||
===== Related Books
|
||||
=== Related Books
|
||||
|
||||
[citetitle]_OpenLDAP by Example_ by John Terpstra and Benjamin Coles; Prentice Hall.:: A collection of practical exercises in the OpenLDAP deployment.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
|
||||
[[sec-Printer_Configuration]]
|
||||
==== Printer Configuration
|
||||
== Printer Configuration
|
||||
indexterm:[CUPS,Printer Configuration]indexterm:[printers,Printer Configuration]
|
||||
The [application]*Printers* configuration tool serves for printer configuring, maintenance of printer configuration files, print spool directories and print filters, and printer classes management.
|
||||
|
||||
|
|
@ -15,7 +15,7 @@ You can perform the same and additional operations on printers directly from the
|
|||
====
|
||||
|
||||
[[sec-Starting_Printer_Config]]
|
||||
===== Starting the Printers Configuration Tool
|
||||
=== Starting the Printers Configuration Tool
|
||||
|
||||
With the [application]*Printers* configuration tool you can perform various operations on existing printers and set up new printers. You can also use CUPS directly (go to link:++http://localhost:631/++[http://localhost:631/] to access the CUPS web application).
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ The `Printers` window depicted in xref:File_and_Print_Servers.adoc#fig-printconf
|
|||
image::printconf-main.png[Printers Configuration window]
|
||||
|
||||
[[sec-Setting_Printer]]
|
||||
===== Starting Printer Setup
|
||||
=== Starting Printer Setup
|
||||
indexterm:[Printer Configuration,New Printer]
|
||||
Printer setup process varies depending on the printer queue type.
|
||||
|
||||
|
|
@ -46,7 +46,7 @@ Follow this procedure to start a manual printer setup:
|
|||
. Select the plus sign to open the `Add a New Printer` dialog. Select the printer from the list or enter its address below.
|
||||
|
||||
[[sec-Adding_Other_Printer]]
|
||||
===== Adding a Local Printer
|
||||
=== Adding a Local Printer
|
||||
indexterm:[Printer Configuration,Local Printers]
|
||||
Follow this procedure to add a local printer connected with other than a serial port:
|
||||
|
||||
|
|
@ -77,7 +77,7 @@ image::print_conf_window.png[Adding a local printer]
|
|||
. Select the printer model. See xref:File_and_Print_Servers.adoc#s1-printing-select-model[Selecting the Printer Model and Finishing] for details.
|
||||
|
||||
[[s1-printing-jetdirect-printer]]
|
||||
===== Adding an AppSocket/HP JetDirect printer
|
||||
=== Adding an AppSocket/HP JetDirect printer
|
||||
|
||||
Follow this procedure to add an AppSocket/HP JetDirect printer:
|
||||
|
||||
|
|
@ -103,7 +103,7 @@ image::printconf-jetdirect.png[Adding a JetDirect Printer]
|
|||
. Select the printer model. See xref:File_and_Print_Servers.adoc#s1-printing-select-model[Selecting the Printer Model and Finishing] for details.
|
||||
|
||||
[[s1-printing-ipp-printer]]
|
||||
===== Adding an IPP Printer
|
||||
=== Adding an IPP Printer
|
||||
indexterm:[Printer Configuration,IPP Printers]
|
||||
An `IPP` printer is a printer attached to a different system on the same TCP/IP network. The system this printer is attached to may either be running CUPS or simply configured to use `IPP`.
|
||||
|
||||
|
|
@ -135,7 +135,7 @@ image::printconf-ipp.png[Networked IPP Printer]
|
|||
. Select the printer model. See xref:File_and_Print_Servers.adoc#s1-printing-select-model[Selecting the Printer Model and Finishing] for details.
|
||||
|
||||
[[sec-printing-LPDLPR-printer]]
|
||||
===== Adding an LPD/LPR Host or Printer
|
||||
=== Adding an LPD/LPR Host or Printer
|
||||
indexterm:[Printer Configuration,LDP/LPR Printers]
|
||||
|
||||
[[proc-Adding_HTTPS_Printer]]
|
||||
|
|
@ -164,7 +164,7 @@ image::printconf-lpd.png[Adding an LPD/LPR Printer]
|
|||
. Select the printer model. See xref:File_and_Print_Servers.adoc#s1-printing-select-model[Selecting the Printer Model and Finishing] for details.
|
||||
|
||||
[[s1-printing-smb-printer]]
|
||||
===== Adding a Samba (SMB) printer
|
||||
=== Adding a Samba (SMB) printer
|
||||
indexterm:[Printer Configuration,Samba Printers]indexterm:[Samba,Samba Printers]
|
||||
|
||||
[[proc-Adding_SMB_Printer]]
|
||||
|
|
@ -226,7 +226,7 @@ If there are files shared on the Samba print server, it is recommended that they
|
|||
. Select the printer model. See xref:File_and_Print_Servers.adoc#s1-printing-select-model[Selecting the Printer Model and Finishing] for details.
|
||||
|
||||
[[s1-printing-select-model]]
|
||||
===== Selecting the Printer Model and Finishing
|
||||
=== Selecting the Printer Model and Finishing
|
||||
|
||||
Once you have properly selected a printer connection type, the system attempts to acquire a driver. If the process fails, you can locate or search for the driver resources manually.
|
||||
|
||||
|
|
@ -286,7 +286,7 @@ image::printconf-add-printer.png[Printer Setup]
|
|||
. After the changes are applied, a dialog box appears allowing you to print a test page. Click btn:[Print Test Page] to print a test page now. Alternatively, you can print a test page later as described in xref:File_and_Print_Servers.adoc#s1-printing-test-page[Printing a Test Page].
|
||||
|
||||
[[s1-printing-test-page]]
|
||||
===== Printing a Test Page
|
||||
=== Printing a Test Page
|
||||
|
||||
[[proc-Printing_Test_Page]]
|
||||
|
||||
|
|
@ -299,13 +299,13 @@ After you have set up a printer or changed a printer configuration, print a test
|
|||
. On the displayed `Settings` tab, click the btn:[Print Test Page] button.
|
||||
|
||||
[[s1-printing-edit]]
|
||||
===== Modifying Existing Printers
|
||||
=== Modifying Existing Printers
|
||||
|
||||
To delete an existing printer, in the `Printer` configuration window, select the printer and go to menu:Printer[pass:attributes[{blank}]`Delete`pass:attributes[{blank}]]. Confirm the printer deletion. Alternatively, press the kbd:[Delete] key.
|
||||
|
||||
To set the default printer, right-click the printer in the printer list and click the `Set As Default` button in the context menu.
|
||||
|
||||
====== The Settings Page
|
||||
==== The Settings Page
|
||||
indexterm:[Printer Configuration,Settings]
|
||||
To change printer driver configuration, double-click the corresponding name in the `Printer` list and click the `Settings` label on the left to display the `Settings` page.
|
||||
|
||||
|
|
@ -316,7 +316,7 @@ You can modify printer settings such as make and model, print a test page, chang
|
|||
|
||||
image::printconf-config1.png[Settings Page]
|
||||
|
||||
====== The Policies Page
|
||||
==== The Policies Page
|
||||
|
||||
Click the `Policies` button on the left to change settings in printer state and print output.
|
||||
|
||||
|
|
@ -400,7 +400,7 @@ The `Ink/Toner Levels` page contains details on toner status if available and pr
|
|||
image::printconf-config6.png[Ink/Toner Levels Page]
|
||||
|
||||
[[s1-printing-managing]]
|
||||
====== Managing Print Jobs
|
||||
==== Managing Print Jobs
|
||||
indexterm:[Printer Configuration,Print Jobs]
|
||||
When you send a print job to the printer daemon, such as printing a text file from [application]*Emacs* or printing an image from [application]*GIMP*, the print job is added to the print spool queue. The print spool queue is a list of print jobs that have been sent to the printer and information about each print request, such as the status of the request, the job number, and more.
|
||||
|
||||
|
|
@ -434,12 +434,12 @@ If you want to cancel a print job, find the job number of the request with the c
|
|||
You can also print a file directly from a shell prompt. For example, the command [command]#lp sample.txt# prints the text file `sample.txt`. The print filter determines what type of file it is and converts it into a format the printer can understand.
|
||||
|
||||
[[s1-printing-additional-resources]]
|
||||
===== Additional Resources
|
||||
=== Additional Resources
|
||||
|
||||
To learn more about printing on {MAJOROS}, see the following resources.
|
||||
|
||||
[[s2-printing-additional-resources-installed]]
|
||||
====== Installed Documentation
|
||||
==== Installed Documentation
|
||||
|
||||
[command]#man lp#:: The manual page for the [command]#lpr# command that allows you to print files from the command line.
|
||||
|
||||
|
|
@ -456,7 +456,7 @@ To learn more about printing on {MAJOROS}, see the following resources.
|
|||
[command]#man lpstat#:: The manual page for the [command]#lpstat# command, which displays status information about classes, jobs, and printers.
|
||||
|
||||
[[s2-printing-additional-resources-websites]]
|
||||
====== Useful Websites
|
||||
==== Useful Websites
|
||||
|
||||
link:++https://wiki.linuxfoundation.org/openprinting/start++[]:: [citetitle]_Open Printing_ contains a large amount of information about printing in Linux.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
|
||||
[[sect-Samba]]
|
||||
==== Samba
|
||||
== Samba
|
||||
indexterm:[Samba,Reference]indexterm:[Samba,Samba]
|
||||
[application]*Samba* is the standard open source Windows interoperability suite of programs for Linux. It implements the _server message block_ (`SMB`) protocol. Modern versions of this protocol are also known as the _common Internet file system_ (`CIFS`) protocol. It allows the networking of Microsoft *Windows*, Linux, UNIX, and other operating systems together, enabling access to Windows-based file and printer shares. Samba's use of `SMB` allows it to appear as a Windows server to Windows clients.
|
||||
|
||||
|
|
@ -20,7 +20,7 @@ For more information on installing packages with DNF, see xref:../package-manage
|
|||
====
|
||||
|
||||
[[sect-Samba-Introduction_to_Samba]]
|
||||
===== Introduction to Samba
|
||||
=== Introduction to Samba
|
||||
indexterm:[Samba,Introduction]
|
||||
Samba is an important component to seamlessly integrate Linux Servers and Desktops into Active Directory (AD) environments. It can function both as a domain controller (NT4-style) or as a regular domain member (AD or NT4-style).
|
||||
indexterm:[Samba,Abilities]
|
||||
|
|
@ -49,7 +49,7 @@ indexterm:[Samba,Abilities]
|
|||
* Act as an Active Directory domain controller
|
||||
|
||||
[[sect-Samba_Daemons_and_Related_Services]]
|
||||
===== Samba Daemons and Related Services
|
||||
=== Samba Daemons and Related Services
|
||||
indexterm:[Samba,daemon,overview]
|
||||
Samba is comprised of three daemons (`smbd`, `nmbd`, and `winbindd`). Three services (`smb`, `nmb`, and `winbind`) control how the daemons are started, stopped, and other service-related features. These services act as different init scripts. Each daemon is listed in detail below, as well as which specific service has control over it.
|
||||
|
||||
|
|
@ -77,7 +77,7 @@ See xref:File_and_Print_Servers.adoc#sect-Samba_Distribution_Programs[Samba Dist
|
|||
====
|
||||
|
||||
[[sect-Samba-Connecting_to_a_Samba_Share]]
|
||||
===== Connecting to a Samba Share
|
||||
=== Connecting to a Samba Share
|
||||
indexterm:[Samba,share,connecting to with Nautilus]
|
||||
You can use either [application]*Nautilus* or command line to connect to available Samba shares.
|
||||
|
||||
|
|
@ -121,7 +121,7 @@ If you see the `smb:\>` prompt, you have successfully logged in. Once you are lo
|
|||
. To exit [command]#smbclient#, type `exit` at the `smb:\>` prompt.
|
||||
|
||||
[[sect-Mounting_the_Samba_Share]]
|
||||
===== Mounting the Share
|
||||
=== Mounting the Share
|
||||
indexterm:[Samba,share,mounting]
|
||||
Sometimes it is useful to mount a Samba share to a directory so that the files in the directory can be treated as if they are part of the local file system.
|
||||
|
||||
|
|
@ -169,17 +169,17 @@ WARNING: This operation can expose passwords by removing password encryption.
|
|||
====
|
||||
|
||||
[[sect-Samba-Configuring_a_Samba_Server]]
|
||||
===== Configuring a Samba Server
|
||||
=== Configuring a Samba Server
|
||||
indexterm:[Samba,configuration]indexterm:[Samba,configuration,default]
|
||||
The default configuration file (`/etc/samba/smb.conf`) allows users to view their home directories as a Samba share. It also shares all printers configured for the system as Samba shared printers. You can attach a printer to the system and print to it from the Windows machines on your network.
|
||||
|
||||
[[sect-Samba-GUI_Configuration]]
|
||||
====== Graphical Configuration
|
||||
==== Graphical Configuration
|
||||
indexterm:[Samba,graphical configuration]
|
||||
To configure Samba using a graphical interface, use one of the available Samba graphical user interfaces. A list of available GUIs can be found at link:++http://www.samba.org/samba/GUI/++[http://www.samba.org/samba/GUI/].
|
||||
|
||||
[[sect-Samba-Command-Line-Configuration]]
|
||||
====== Command-Line Configuration
|
||||
==== Command-Line Configuration
|
||||
indexterm:[Samba,configuration]
|
||||
Samba uses `/etc/samba/smb.conf` as its configuration file. If you change this configuration file, the changes do not take effect until you restart the Samba daemon with the following command, as `root`:
|
||||
|
||||
|
|
@ -221,7 +221,7 @@ create mask = 0765
|
|||
The above example allows the users [command]#tfox# and [command]#carole# to read and write to the directory `/home/share/`, on the Samba server, from a Samba client.
|
||||
|
||||
[[sect-Samba-Encrypted_Passwords]]
|
||||
====== Encrypted Passwords
|
||||
==== Encrypted Passwords
|
||||
|
||||
Encrypted passwords are enabled by default because it is more secure to use them. To create a user with an encrypted password, use the `smbpasswd` utility:
|
||||
|
||||
|
|
@ -232,7 +232,7 @@ Encrypted passwords are enabled by default because it is more secure to use them
|
|||
indexterm:[Samba,with Windows NT 4.0, 2000, ME, and XP]indexterm:[Windows NT 4.0,connecting to shares using Samba]indexterm:[Windows 98,connecting to shares using Samba]indexterm:[Windows 2000,connecting to shares using Samba]indexterm:[Windows ME,connecting to shares using Samba]indexterm:[Windows XP,connecting to shares using Samba]indexterm:[Samba,encrypted passwords]
|
||||
|
||||
[[sect-Samba-Starting_and_Stopping]]
|
||||
===== Starting and Stopping Samba
|
||||
=== Starting and Stopping Samba
|
||||
indexterm:[Samba,service,starting]indexterm:[Samba,service,stopping]indexterm:[Samba,service,restarting]indexterm:[Samba,service,conditional restarting]indexterm:[Samba,service,reloading]
|
||||
To start a Samba server, type the following command in a shell prompt, as `root`:
|
||||
|
||||
|
|
@ -299,14 +299,14 @@ By default, the `smb` service does *not* start automatically at boot time. To co
|
|||
See xref:../infrastructure-services/Services_and_Daemons.adoc#ch-Services_and_Daemons[Services and Daemons] for more information regarding this tool.
|
||||
|
||||
[[sect-Samba-Server_Types_and_the_smb.conf_File]]
|
||||
===== Samba Server Types and the `smb.conf` File
|
||||
=== Samba Server Types and the `smb.conf` File
|
||||
indexterm:[Samba,smb.conf]indexterm:[Samba,Server Types]
|
||||
Samba configuration is straightforward. All modifications to Samba are done in the `/etc/samba/smb.conf` configuration file. Although the default `smb.conf` file is well documented, it does not address complex topics such as LDAP, Active Directory, and the numerous domain controller implementations.
|
||||
|
||||
The following sections describe the different ways a Samba server can be configured. Keep in mind your needs and the changes required to the `/etc/samba/smb.conf` file for a successful configuration.
|
||||
|
||||
[[sect-Samba-Standalone_Server]]
|
||||
====== Stand-alone Server
|
||||
==== Stand-alone Server
|
||||
indexterm:[Samba,server types,Stand Alone]
|
||||
A stand-alone server can be a workgroup server or a member of a workgroup environment. A stand-alone server is not a domain controller and does not participate in a domain in any way. The following examples include several user-level security configurations. For more information on security modes, see xref:File_and_Print_Servers.adoc#sect-Samba-Security_Modes[Samba Security Modes].
|
||||
|
||||
|
|
@ -440,7 +440,7 @@ browseable = yes
|
|||
====
|
||||
|
||||
[[sect-Samba-Domain_Member_Server]]
|
||||
====== Domain Member Server
|
||||
==== Domain Member Server
|
||||
indexterm:[Samba,server types,Domain Member]
|
||||
A domain member, while similar to a stand-alone server, is logged into a domain controller (either Windows or Samba) and is subject to the domain's security rules. An example of a domain member server would be a departmental server running Samba that has a machine account on the Primary Domain Controller (PDC). All of the department's clients still authenticate with the PDC, and desktop profiles and all network policy files are included. The difference is that the departmental server has the ability to control printer and network shares.
|
||||
|
||||
|
|
@ -560,7 +560,7 @@ After configuring the `/etc/samba/smb.conf` file, join the domain *before* start
|
|||
Note that the [option]`-S` option, which specifies the domain server host name, does not need to be stated in the [command]#net rpc join# command. Samba uses the host name specified by the `workgroup` directive in the `/etc/samba/smb.conf` file instead of it being stated explicitly.
|
||||
|
||||
[[sect-Samba-Domain_Controller]]
|
||||
====== Domain Controller
|
||||
==== Domain Controller
|
||||
indexterm:[Samba,server types,Domain Controller]
|
||||
A domain controller in Windows NT is functionally similar to a Network Information Service (NIS) server in a Linux environment. Domain controllers and NIS servers both host user and group information databases as well as related services. Domain controllers are mainly used for security, including the authentication of users accessing domain resources. The service that maintains the user and group database integrity is called the _Security Account Manager_ (SAM). The SAM database is stored differently between Windows and Linux Samba-based systems, therefore SAM replication cannot be achieved and platforms cannot be mixed in a PDC/BDC environment.
|
||||
|
||||
|
|
@ -692,12 +692,12 @@ If you need more than one domain controller or have more than 250 users, do *not
|
|||
Although it is possible for Samba to be a member of an Active Directory, it is not possible for Samba to operate as an Active Directory domain controller.
|
||||
|
||||
[[sect-Samba-Security_Modes]]
|
||||
===== Samba Security Modes
|
||||
=== Samba Security Modes
|
||||
indexterm:[Samba,Security Modes]
|
||||
There are only two types of security modes for Samba, _share-level_ and _user-level_, which are collectively known as *pass:attributes[{blank}]_security levels_pass:attributes[{blank}]*. Share-level security is deprecated and has been removed from Samba. Configurations containing this mode need to be migrated to use user-level security. User-level security can be implemented in one of three different ways. The different ways of implementing a security level are called _security modes_.
|
||||
|
||||
[[sect-Samba_Security_Modes-User_Level]]
|
||||
====== User-Level Security
|
||||
==== User-Level Security
|
||||
indexterm:[Samba,Security Modes,User Level Security]
|
||||
User-level security is the default and recommended setting for Samba. Even if the `security = user` directive is not listed in the `/etc/samba/smb.conf` file, it is used by Samba. If the server accepts the client's user name and password, the client can then mount multiple shares without specifying a password for each instance. Samba can also accept session-based user name and password requests. The client maintains multiple authentication contexts by using a unique UID for each logon.
|
||||
|
||||
|
|
@ -781,12 +781,12 @@ password server = kerberos.example.com
|
|||
----
|
||||
|
||||
[[sect-Samba_Security_Modes-Share_Level]]
|
||||
====== Share-Level Security
|
||||
==== Share-Level Security
|
||||
indexterm:[Samba,Security Modes,Share-Level Security]
|
||||
With share-level security, the server accepts only a password without an explicit user name from the client. The server expects a password for each share, independent of the user name. There have been recent reports that Microsoft Windows clients have compatibility issues with share-level security servers. This mode is deprecated and has been removed from Samba. Configurations containing `security = share` should be updated to use user-level security. Follow the steps in xref:File_and_Print_Servers.adoc#proc-Samba_Security_Modes-Samba_Guest_Shares[Configuring Samba Guest Shares] to avoid using the `security = share` directive.
|
||||
|
||||
[[sect-Samba-Account_Information-Databases]]
|
||||
===== Samba Account Information Databases
|
||||
=== Samba Account Information Databases
|
||||
indexterm:[Samba,Account Information Databases]
|
||||
The following is a list different back ends you can use with Samba. Other back ends not listed here may also be available.
|
||||
indexterm:[Samba,Backward Compatible Database Back Ends]indexterm:[Samba,Account Information Databases,Plain Text]indexterm:[Samba,Account Information Databases,smbpasswd]indexterm:[Samba,Account Information Databases,ldapsam_compat]indexterm:[Samba,New Database Back Ends]indexterm:[Samba,Account Information Databases,tdbsam]indexterm:[Samba,Account Information Databases,ldapsam]indexterm:[Samba,Account Information Databases,mysqlsam]indexterm:[Samba,Account Information Databases,xmlsam]
|
||||
|
|
@ -820,7 +820,7 @@ You need to have the [package]*openldap-servers* package installed if you want t
|
|||
====
|
||||
|
||||
[[sect-Samba-Network_Browsing]]
|
||||
===== Samba Network Browsing
|
||||
=== Samba Network Browsing
|
||||
indexterm:[Samba,Network Browsing]indexterm:[Samba,Browsing]
|
||||
_Network browsing_ enables Windows and Samba servers to appear in the Windows `Network Neighborhood`. Inside the `Network Neighborhood`, icons are represented as servers and if opened, the server's shares and printers that are available are displayed.
|
||||
|
||||
|
|
@ -829,14 +829,14 @@ Network browsing capabilities require NetBIOS over `TCP`pass:attributes[{blank}]
|
|||
A domain master browser collates the browse lists from local master browsers on all subnets so that browsing can occur between workgroups and subnets. Also, the domain master browser should preferably be the local master browser for its own subnet.
|
||||
|
||||
[[sect-Samba-Domain-Browsing]]
|
||||
====== Domain Browsing
|
||||
==== Domain Browsing
|
||||
indexterm:[Samba,Network Browsing,Domain Browsing]
|
||||
By default, a Windows server PDC for a domain is also the domain master browser for that domain. A Samba server must *not* be set up as a domain master server in this type of situation.
|
||||
|
||||
For subnets that do not include the Windows server PDC, a Samba server can be implemented as a local master browser. Configuring the `/etc/samba/smb.conf` file for a local master browser (or no browsing at all) in a domain controller environment is the same as workgroup configuration (see xref:File_and_Print_Servers.adoc#sect-Samba-Configuring_a_Samba_Server[Configuring a Samba Server]).
|
||||
|
||||
[[sect-Samba-WINS]]
|
||||
====== WINS (Windows Internet Name Server)
|
||||
==== WINS (Windows Internet Name Server)
|
||||
indexterm:[Samba,WINS]indexterm:[Samba,Network Browsing,WINS]
|
||||
Either a Samba server or a Windows NT server can function as a WINS server. When a WINS server is used with NetBIOS enabled, UDP unicasts can be routed which allows name resolution across networks. Without a WINS server, the UDP broadcast is limited to the local subnet and therefore cannot be routed to other subnets, workgroups, or domains. If WINS replication is necessary, do not use Samba as your primary WINS server, as Samba does not currently support WINS replication.
|
||||
|
||||
|
|
@ -866,12 +866,12 @@ All servers (including Samba) should connect to a WINS server to resolve NetBIOS
|
|||
====
|
||||
|
||||
[[sect-Samba_with_CUPS_Printing_Support]]
|
||||
===== Samba with CUPS Printing Support
|
||||
=== Samba with CUPS Printing Support
|
||||
indexterm:[Samba,CUPS Printing Support]
|
||||
Samba allows client machines to share printers connected to the Samba server. In addition, Samba also allows client machines to send documents built in Linux to Windows printer shares. Although there are other printing systems that function with {MAJOROS}, CUPS (Common UNIX Print System) is the recommended printing system due to its close integration with Samba.
|
||||
|
||||
[[sect-Samba-CUPS-smb.conf]]
|
||||
====== Simple `smb.conf` Settings
|
||||
==== Simple `smb.conf` Settings
|
||||
indexterm:[Samba,CUPS Printing Support,CUPS smb.conf]
|
||||
The following example shows a very basic `/etc/samba/smb.conf` configuration for CUPS support:
|
||||
|
||||
|
|
@ -910,7 +910,7 @@ The `print$` directive contains printer drivers for clients to access if not ava
|
|||
Setting `browseable` to `yes` enables the printer to be viewed in the Windows Network Neighborhood, provided the Samba server is set up correctly in the domain or workgroup.
|
||||
|
||||
[[sect-Samba_Distribution_Programs]]
|
||||
===== Samba Distribution Programs
|
||||
=== Samba Distribution Programs
|
||||
indexterm:[Samba,Programs]
|
||||
.`net`pass:attributes[{blank}]indexterm:[Samba,Programs,net]indexterm:[net program]
|
||||
----
|
||||
|
|
@ -1161,7 +1161,7 @@ pass:quotes[`<enter>`]
|
|||
The `wbinfo` program displays information from the `winbindd` daemon. The `winbindd` daemon must be running for `wbinfo` to work.
|
||||
|
||||
[[sect-Samba-Resources]]
|
||||
===== Additional Resources
|
||||
=== Additional Resources
|
||||
indexterm:[Samba,Additional Resources]
|
||||
The following sections give you the means to explore Samba in greater detail.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
|
||||
[[s1-The_Apache_HTTP_Server]]
|
||||
==== The Apache HTTP Server
|
||||
== The Apache HTTP Server
|
||||
indexterm:[httpd,Apache HTTP Server]
|
||||
The web server available in {MAJOROS} is the Apache HTTP server daemon, `httpd`, an open source web server developed by the link:++http://www.apache.org/++[Apache Software Foundation]. In Fedora 19 the Apache server was updated to [application]*Apache HTTP Server 2.4*. This section describes the basic configuration of the `httpd` service, and covers some advanced topics such as adding server modules, setting up virtual hosts, or configuring the secure HTTP server.
|
||||
|
||||
There are important differences between the Apache HTTP Server 2.4 and version 2.2, and if you are upgrading from a release prior to Fedora 19, you will need to update the `httpd` service configuration accordingly. This section reviews some of the newly added features, outlines important changes, and guides you through the update of older configuration files.
|
||||
|
||||
[[s2-apache-changes]]
|
||||
===== Notable Changes
|
||||
=== Notable Changes
|
||||
indexterm:[Apache HTTP Server,version 2.4,changes]
|
||||
The Apache HTTP Server version 2.4 has the following changes compared to version 2.2:
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ mod_perl::: [application]*mod_perl* is not officially supported with [applicatio
|
|||
mod_authz_ldap::: [application]*httpd 2.4* provides LDAP support in sub-package [package]*mod_ldap* using [application]*mod_authnz_ldap*.
|
||||
|
||||
[[s2-apache-version2-migrating]]
|
||||
===== Updating the Configuration
|
||||
=== Updating the Configuration
|
||||
indexterm:[Apache HTTP Server,version 2.4,updating from version 2.2]
|
||||
To update the configuration files from the Apache HTTP Server version 2.2, take the following steps:
|
||||
|
||||
|
|
@ -120,7 +120,7 @@ Syntax OK
|
|||
For more information on upgrading the Apache HTTP Server configuration from version 2.2 to 2.4, see link:++http://httpd.apache.org/docs/2.4/upgrading.html++[].
|
||||
|
||||
[[s2-apache-running]]
|
||||
===== Running the httpd Service
|
||||
=== Running the httpd Service
|
||||
|
||||
This section describes how to start, stop, restart, and check the current status of the Apache HTTP Server. To be able to use the `httpd` service, make sure you have the [package]*httpd* installed. You can do so by using the following command:
|
||||
|
||||
|
|
@ -134,7 +134,7 @@ For more information on the concept of targets and how to manage system services
|
|||
xref:../infrastructure-services/Services_and_Daemons.adoc#ch-Services_and_Daemons[Services and Daemons].
|
||||
|
||||
[[s3-apache-running-starting]]
|
||||
====== Starting the Service
|
||||
==== Starting the Service
|
||||
indexterm:[Apache HTTP Server,starting]
|
||||
To run the `httpd` service, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -160,7 +160,7 @@ If running the Apache HTTP Server as a secure server, a password may be required
|
|||
====
|
||||
|
||||
[[s3-apache-running-stopping]]
|
||||
====== Stopping the Service
|
||||
==== Stopping the Service
|
||||
indexterm:[Apache HTTP Server,stopping]
|
||||
To stop the running `httpd` service, type the following at a shell prompt as `root`:
|
||||
|
||||
|
|
@ -178,7 +178,7 @@ rm '/etc/systemd/system/multi-user.target.wants/httpd.service'
|
|||
----
|
||||
|
||||
[[s3-apache-running-restarting]]
|
||||
====== Restarting the Service
|
||||
==== Restarting the Service
|
||||
indexterm:[Apache HTTP Server,restarting]
|
||||
There are three different ways to restart a running `httpd` service:
|
||||
|
||||
|
|
@ -210,7 +210,7 @@ This causes the running `httpd` service to reload its configuration file. Any re
|
|||
This causes the running `httpd` service to reload its configuration file. Any requests currently being processed will continue to use the old configuration.
|
||||
|
||||
[[s3-apache-running-status]]
|
||||
====== Verifying the Service Status
|
||||
==== Verifying the Service Status
|
||||
indexterm:[Apache HTTP Server,checking status]
|
||||
To verify that the `httpd` service is running, type the following at a shell prompt:
|
||||
|
||||
|
|
@ -221,7 +221,7 @@ active
|
|||
----
|
||||
|
||||
[[s2-apache-editing]]
|
||||
===== Editing the Configuration Files
|
||||
=== Editing the Configuration Files
|
||||
|
||||
When the `httpd` service is started, by default, it reads the configuration from locations that are listed in xref:Web_Servers.adoc#table-apache-editing-files[The httpd service configuration files].
|
||||
|
||||
|
|
@ -250,7 +250,7 @@ Syntax OK
|
|||
To make the recovery from mistakes easier, it is recommended that you make a copy of the original file before editing it.
|
||||
|
||||
[[s3-apache-httpdconf-directives]]
|
||||
====== Common httpd.conf Directives
|
||||
==== Common httpd.conf Directives
|
||||
indexterm:[Apache HTTP Server,files,/etc/httpd/conf/httpd.conf]
|
||||
The following directives are commonly used in the `/etc/httpd/conf/httpd.conf` configuration file:
|
||||
|
||||
|
|
@ -2000,7 +2000,7 @@ UserDir public_html
|
|||
====
|
||||
|
||||
[[s3-apache-sslconf-common]]
|
||||
====== Common ssl.conf Directives
|
||||
==== Common ssl.conf Directives
|
||||
|
||||
The _Secure Sockets Layer_ (*SSL*) directives allow you to customize the behavior of the Apache HTTP Secure Server, and in most cases, they are configured appropriately during the installation. Be careful when changing these settings, as incorrect configuration can lead to security vulnerabilities.
|
||||
indexterm:[Apache HTTP Server,files,/etc/httpd/conf.d/ssl.conf]
|
||||
|
|
@ -2046,7 +2046,7 @@ SetEnvIf User-Agent ".*MSIE.*" \
|
|||
Note that for the `/etc/httpd/conf.d/ssl.conf` file to be present, the [package]*mod_ssl* needs to be installed. See xref:Web_Servers.adoc#s2-apache-mod_ssl[Setting Up an SSL Server] for more information on how to install and configure an SSL server.
|
||||
|
||||
[[s3-apache-mpm-common]]
|
||||
====== Common Multi-Processing Module Directives
|
||||
==== Common Multi-Processing Module Directives
|
||||
|
||||
The _Multi-Processing Module_ (*MPM*) directives allow you to customize the behavior of a particular MPM specific server-pool. Since its characteristics differ depending on which MPM is used, the directives are embedded in [option]`IfModule`. By default, the server-pool is defined for both the `prefork` and `worker` MPMs.
|
||||
indexterm:[Apache HTTP Server,files,/etc/httpd/conf/httpd.conf]
|
||||
|
|
@ -2215,12 +2215,12 @@ ThreadsPerChild 25
|
|||
====
|
||||
|
||||
[[s2-apache-dso]]
|
||||
===== Working with Modules
|
||||
=== Working with Modules
|
||||
indexterm:[Apache HTTP Server,directories,/usr/lib/httpd/modules/]indexterm:[Apache HTTP Server,directories,/usr/lib64/httpd/modules/]
|
||||
Being a modular application, the `httpd` service is distributed along with a number of _Dynamic Shared Objects_ (*DSO*pass:attributes[{blank}]s), which can be dynamically loaded or unloaded at runtime as necessary. By default, these modules are located in `/usr/lib/httpd/modules/` on 32-bit and in `/usr/lib64/httpd/modules/` on 64-bit systems.
|
||||
|
||||
[[s3-apache-dso-loading]]
|
||||
====== Loading a Module
|
||||
==== Loading a Module
|
||||
indexterm:[Apache HTTP Server,modules,loading]
|
||||
To load a particular DSO module, use the [option]`LoadModule` directive as described in xref:Web_Servers.adoc#s3-apache-httpdconf-directives[Common httpd.conf Directives]. Note that modules provided by a separate package often have their own configuration file in the `/etc/httpd/conf.d/` directory.
|
||||
|
||||
|
|
@ -2237,7 +2237,7 @@ LoadModule ssl_module modules/mod_ssl.so
|
|||
Once you are finished, restart the web server to reload the configuration. See xref:Web_Servers.adoc#s3-apache-running-restarting[Restarting the Service] for more information on how to restart the `httpd` service.
|
||||
|
||||
[[s3-apache-dso-writing]]
|
||||
====== Writing a Module
|
||||
==== Writing a Module
|
||||
indexterm:[Apache HTTP Server,modules,developing]
|
||||
If you intend to create a new DSO module, make sure you have the [package]*httpd-devel* package installed. To do so, enter the following command as `root`:
|
||||
|
||||
|
|
@ -2258,7 +2258,7 @@ Once written, you can build the module with the following command:
|
|||
If the build was successful, you should be able to load the module the same way as any other module that is distributed with the Apache HTTP Server.
|
||||
|
||||
[[s2-apache-virtualhosts]]
|
||||
===== Setting Up Virtual Hosts
|
||||
=== Setting Up Virtual Hosts
|
||||
indexterm:[Apache HTTP Server,virtual host]indexterm:[virtual host,Apache HTTP Server]
|
||||
The Apache HTTP Server's built in virtual hosting allows the server to provide different information based on which IP address, host name, or port is being requested.
|
||||
|
||||
|
|
@ -2295,14 +2295,14 @@ If you configure a virtual host to listen on a non-default port, make sure you u
|
|||
To activate a newly created virtual host, the web server has to be restarted first. See xref:Web_Servers.adoc#s3-apache-running-restarting[Restarting the Service] for more information on how to restart the `httpd` service.
|
||||
|
||||
[[s2-apache-mod_ssl]]
|
||||
===== Setting Up an SSL Server
|
||||
=== Setting Up an SSL Server
|
||||
indexterm:[Apache HTTP Server,modules,mod_ssl]indexterm:[SSL server,Apache HTTP Server]indexterm:[SSL,Apache HTTP Server]indexterm:[TLS,Apache HTTP Server]indexterm:[OpenSSL,SSL,SSL]indexterm:[OpenSSL,TLS,TLS]
|
||||
_Secure Sockets Layer_ (*SSL*) is a cryptographic protocol that allows a server and a client to communicate securely. Along with its extended and improved version called _Transport Layer Security_ (*TLS*), it ensures both privacy and data integrity. The Apache HTTP Server in combination with `mod_ssl`, a module that uses the OpenSSL toolkit to provide the SSL/TLS support, is commonly referred to as the _SSL server_.
|
||||
|
||||
Unlike a regular HTTP connection that can be read and possibly modified by anybody who is able to intercept it, the use of `mod_ssl` prevents any inspection or modification of the transmitted content. This section provides basic information on how to enable this module in the Apache HTTP Server configuration, and guides you through the process of generating private keys and self-signed certificates.
|
||||
|
||||
[[s3-apache-mod_ssl-certificates]]
|
||||
====== An Overview of Certificates and Security
|
||||
==== An Overview of Certificates and Security
|
||||
indexterm:[Apache HTTP Server,SSL server,private key]indexterm:[Apache HTTP Server,SSL server,public key]
|
||||
Secure communication is based on the use of keys. In conventional or _symmetric cryptography_, both ends of the transaction have the same key they can use to decode each other's transmissions. On the other hand, in public or _asymmetric cryptography_, two keys co-exist: a _private key_ that is kept a secret, and a _public key_ that is usually shared with the public. While the data encoded with the public key can only be decoded with the private key, data encoded with the private key can in turn only be decoded with the public key.
|
||||
indexterm:[Apache HTTP Server,SSL server,certificate]indexterm:[Apache HTTP Server,SSL server,certificate authority]
|
||||
|
|
@ -2327,7 +2327,7 @@ By default, most web browsers are configured to trust a set of widely used certi
|
|||
When setting up an SSL server, you need to generate a certificate request and a private key, and then send the certificate request, proof of the company's identity, and payment to a certificate authority. Once the CA verifies the certificate request and your identity, it will send you a signed certificate you can use with your server. Alternatively, you can create a self-signed certificate that does not contain a CA signature, and thus should be used for testing purposes only.
|
||||
|
||||
[[s3-apache-mod_ssl-enabling]]
|
||||
====== Enabling the mod_ssl Module
|
||||
==== Enabling the mod_ssl Module
|
||||
|
||||
If you intend to set up an SSL server, make sure you have the [package]*mod_ssl* (the `mod_ssl` module) and [package]*openssl* (the OpenSSL toolkit) packages installed. To do so, enter the following command as `root`:
|
||||
|
||||
|
|
@ -2346,7 +2346,7 @@ Due to the SSL3.0 protocol vulnerability CVE-2014-3566, described in link:++http
|
|||
====
|
||||
|
||||
[[s3-apache-Enabling_and_Disabling_SSL_and_TLS_in_mod_ssl]]
|
||||
====== Enabling and Disabling SSL and TLS in mod_ssl
|
||||
==== Enabling and Disabling SSL and TLS in mod_ssl
|
||||
|
||||
To disable and enable specific versions of the SSL and TLS protocol, either do it globally by adding the [command]#SSLProtocol# directive in the "## SSL Global Context" section of the configuration file and removing it everywhere else, or edit the default entry under "# SSL Protocol support" in all "VirtualHost" sections. If you do not specify it in the per-domain VirtualHost section then it will inherit the settings from the global section. To make sure that a protocol version is being disabled the administrator should either *only* specify [command]#SSLProtocol# in the "SSL Global Context" section, or specify it in *all* per-domain VirtualHost sections.
|
||||
|
||||
|
|
@ -2396,7 +2396,7 @@ This step is particularly important if you have more than the one default Virtua
|
|||
Note that any sessions will be interrupted.
|
||||
|
||||
[[s3-apache-mod_ssl-keypair]]
|
||||
====== Using an Existing Key and Certificate
|
||||
==== Using an Existing Key and Certificate
|
||||
indexterm:[Apache HTTP Server,SSL server,private key]indexterm:[Apache HTTP Server,SSL server,certificate]
|
||||
If you have a previously created key and certificate, you can configure the SSL server to use these files instead of generating new ones. There are only two situations where this is not possible:
|
||||
|
||||
|
|
@ -2441,7 +2441,7 @@ To load the updated configuration, restart the `httpd` service as described in x
|
|||
====
|
||||
|
||||
[[s3-apache-mod_ssl-genkey]]
|
||||
====== Generating a New Key and Certificate
|
||||
==== Generating a New Key and Certificate
|
||||
indexterm:[Apache HTTP Server,SSL server,private key]indexterm:[Apache HTTP Server,SSL server,certificate]
|
||||
In order to generate a new key and certificate pair, the [package]*crypto-utils* package must be installed on the system. To install it, enter the following command as `root`:
|
||||
|
||||
|
|
@ -2569,7 +2569,7 @@ SSLCertificateKeyFile /etc/pki/tls/private/pass:attributes[{blank}]_hostname_.ke
|
|||
Finally, restart the `httpd` service as described in xref:Web_Servers.adoc#s3-apache-running-restarting[Restarting the Service], so that the updated configuration is loaded.
|
||||
|
||||
[[s2-apache-resources]]
|
||||
===== Additional Resources
|
||||
=== Additional Resources
|
||||
|
||||
To learn more about the Apache HTTP Server, see the following resources.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
include::en-US/entities.adoc[]
|
||||
|
||||
[[ch-Web_Servers]]
|
||||
=== Web Servers
|
||||
= Web Servers
|
||||
indexterm:[HTTP server,Apache HTTP Server]indexterm:[web server,Apache HTTP Server]
|
||||
A _web server_ is a network service that serves content to a client over the web. This typically means web pages, but any other documents can be served as well. Web servers are also known as HTTP servers, as they use the _hypertext transport protocol_ (*HTTP*).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
== Servers
|
||||
= Servers
|
||||
|
||||
This part discusses various topics related to servers such as how to set up a web server or share files and directories over a network.
|
||||
|
|
|
|||
Reference in a new issue