[system-administrators-guide] Add sec- to section IDs, s1 and s2 to sec
by stephenw
commit d2aaa69d59d15bcc833f70e466cfcd4c7d50d2d2
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Wed Jul 30 23:40:13 2014 +0200
Add sec- to section IDs, s1 and s2 to sec
en-US/Configuring_PTP_Using_ptp4l.xml | 38 ++++++++++++++++----------------
1 files changed, 19 insertions(+), 19 deletions(-)
---
diff --git a/en-US/Configuring_PTP_Using_ptp4l.xml b/en-US/Configuring_PTP_Using_ptp4l.xml
index c0ac008..7288ff7 100644
--- a/en-US/Configuring_PTP_Using_ptp4l.xml
+++ b/en-US/Configuring_PTP_Using_ptp4l.xml
@@ -5,7 +5,7 @@
<chapter id="ch-Configuring_PTP_Using_ptp4l">
<title>Configuring PTP Using ptp4l</title>
- <section id="Introduction_to_PTP">
+ <section id="sec-Introduction_to_PTP">
<title>Introduction to PTP</title>
<para>
The <firstterm>Precision Time Protocol</firstterm> (<acronym>PTP</acronym>) is a protocol used to synchronize clocks in a network. When used in conjunction with hardware support, <systemitem class="protocol">PTP</systemitem> is capable of sub-microsecond accuracy, which is far better than is normally obtainable with <systemitem class="protocol">NTP</systemitem>. <systemitem class="protocol">PTP</systemitem> support is divided between the kernel and user space. The kernel in <application>Fedora</application> includes support for <systemitem class="protocol">PTP</systemitem> clocks, which are provided by network drivers. The actual implementation of the protocol is known as <application>linuxptp</application>, a <systemitem class="protocol">PTPv2</systemitem> implementation according to the IEEE standard 1588 for Linux.
@@ -13,7 +13,7 @@
<para>
The <package>linuxptp</package> package includes the <application>ptp4l</application> and <application>phc2sys</application> programs for clock synchronization. The <application>ptp4l</application> program implements the <systemitem class="protocol">PTP</systemitem> boundary clock and ordinary clock. With hardware time stamping, it is used to synchronize the <systemitem class="protocol">PTP</systemitem> hardware clock to the master clock, and with software time stamping it synchronizes the system clock to the master clock. The <application>phc2sys</application> program is needed only with hardware time stamping, for synchronizing the system clock to the <systemitem class="protocol">PTP</systemitem> hardware clock on the <firstterm>network interface card</firstterm> (<acronym>NIC</acronym>).
</para>
- <section id="Understanding_PTP">
+ <section id="sec-Understanding_PTP">
<title>Understanding PTP</title>
<para>
The clocks synchronized by <systemitem class="protocol">PTP</systemitem> 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 <firstterm>best master clock</firstterm> (<acronym>BMC</acronym>) algorithm, which runs on every clock. When a clock has only one port, it can be <firstterm>master</firstterm> or <firstterm>slave</firstterm>, such a clock is called an <firstterm>ordinary clock</firstterm> (<acronym>OC</acronym>). A clock with multiple ports can be master on one port and slave on another, such a clock is called a <firstterm>boundary</firstterm> clock (<acronym>BC</acronym>). The top-level master is called the <firstterm>grandmaster clock</firstterm>, which can be synchronized by using a <firstterm>Global Positioning System</firstterm> (<acronym>GPS</acronym>) time source. By using a GPS-based time source, disparate networks can be
synchronized with a high-degree of accuracy.
@@ -32,7 +32,7 @@
</mediaobject>
</figure>
</section>
- <section id="s2-Advantages_of_PTP">
+ <section id="sec-Advantages_of_PTP">
<title>Advantages of PTP</title>
<para>
One of the main advantages that <systemitem class="protocol">PTP</systemitem> has over the <firstterm>Network Time Protocol</firstterm> (<acronym>NTP</acronym>) is hardware support present in various <firstterm>network interface controllers</firstterm> (<acronym>NIC</acronym>) and network switches. This specialized hardware allows <systemitem class="protocol">PTP</systemitem> 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 <systemitem class="protocol">PTP</systemitem> clocks are <systemitem class="protocol">PTP</systemitem> hardware en
abled. Time synchronization in larger networks where not all of the networking hardware supports <systemitem class="protocol">PTP</systemitem> might be better suited for <systemitem class="protocol">NTP</systemitem>.
@@ -45,13 +45,13 @@
<!-- Topics, Tasks -->
-<section id="Using_PTP">
+<section id="sec-Using_PTP">
<title>Using PTP</title>
<para>
In order to use <systemitem class="protocol">PTP</systemitem>, the kernel network driver for the intended interface has to support either software or hardware time stamping capabilities.
</para>
- <section id="Checking_for_Driver_and_Hardware_Support">
+ <section id="sec-Checking_for_Driver_and_Hardware_Support">
<title>Checking for Driver and Hardware Support</title>
<para>
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</application> utility to query the interface as follows:
@@ -131,7 +131,7 @@ should include:
</para>
</section>
-<section id="Installing_PTP">
+<section id="sec-Installing_PTP">
<title>Installing PTP</title>
<para>
The kernel in <application>Fedora</application> includes support for <systemitem class="protocol">PTP</systemitem>. User space support is provided by the tools in the <application>linuxptp</application> package. To install <application>linuxptp</application>, issue the following command as <systemitem class="username">root</systemitem>:
@@ -139,11 +139,11 @@ should include:
This will install <application>ptp4l</application> and <application>phc2sys</application>.
</para>
<para>
- Do not run more than one service to set the system clock's time at the same time. If you intend to serve <systemitem class="protocol">PTP</systemitem> time using <systemitem class="protocol">NTP</systemitem>, see <xref linkend="Serving_PTP_Time_with_NTP" />.
+ Do not run more than one service to set the system clock's time at the same time. If you intend to serve <systemitem class="protocol">PTP</systemitem> time using <systemitem class="protocol">NTP</systemitem>, see <xref linkend="sec-Serving_PTP_Time_with_NTP" />.
</para>
</section>
-<section id="Starting_ptp4l">
+<section id="sec-Starting_ptp4l">
<title>Starting ptp4l</title>
<para>
The <application>ptp4l</application> program tries to use hardware time stamping by default. To use <application>ptp4l</application> with hardware time stamping capable drivers and NICs, you must provide the network interface to use with the <option>-i</option> option. Enter the following command as <systemitem class="username">root</systemitem>:
@@ -179,7 +179,7 @@ By default, messages are sent to <filename>/var/log/messages</filename>. However
<screen>~]# <command>ptp4l -i <replaceable>em3</replaceable> -m -S</command></screen>
</para>
- <section id="Selecting_a_Delay_Mechanism">
+ <section id="sec-Selecting_a_Delay_Mechanism">
<title>Selecting a Delay Measurement Mechanism</title>
<para>
There are two different delay measurement mechanisms and they can be selected by means of an option added to the <command>ptp4l</command> command as follows:
@@ -229,7 +229,7 @@ By default, messages are sent to <filename>/var/log/messages</filename>. However
</section>
</section>
-<section id="Specifying_a_Configuration_File">
+<section id="sec-Specifying_a_Configuration_File">
<title>Specifying a Configuration File</title>
<para>
The command line options and other options, which cannot be set on the command line, can be set in an optional configuration file.
@@ -249,7 +249,7 @@ time_stamping software
</para>
</section>
-<section id="Using_the_PTP_Management_Client">
+<section id="sec-Using_the_PTP_Management_Client">
<title>Using the PTP Management Client</title>
<para>
The <systemitem class="protocol">PTP</systemitem> management client, <application>pmc</application>, can be used to obtain additional information from <application>ptp4l</application> as follows:
@@ -312,7 +312,7 @@ if <literal>gmPresent</literal> is true, the <systemitem class="protocol">PTP</s
</para>
</section>
-<section id="Synchronizing_the_Clocks">
+<section id="sec-Synchronizing_the_Clocks">
<title>Synchronizing the Clocks</title>
<para>
The <application>phc2sys</application> program is used to synchronize the system clock to the <systemitem class="protocol">PTP</systemitem> hardware clock (<acronym>PHC</acronym>) on the NIC. To start <application>phc2sys</application>, where <replaceable>em3</replaceable> is the interface with the <systemitem class="protocol">PTP</systemitem> hardware clock, enter the following command as <systemitem class="username">root</systemitem>:
@@ -335,7 +335,7 @@ When running as a service, options are specified in the <filename>/etc/sysconfig
</para>
</section>
-<section id="Verifying_Time_Synchronization">
+<section id="sec-Verifying_Time_Synchronization">
<title>Verifying Time Synchronization</title>
<para>
When <systemitem class="protocol">PTP</systemitem> time synchronization is working properly, new messages with offsets and frequency adjustments will be printed periodically to the <application>ptp4l</application> and <application>phc2sys</application> (if hardware time stamping is used) outputs. These values will eventually converge after a short period of time. These messages can be seen in <filename>/var/log/messages</filename> file. An example of the output follows:
@@ -426,7 +426,7 @@ phc2sys[1060.984]: rms 266 max 675 freq -36759 ± 234 delay 2753 ± 17
</para>
</section>
-<section id="Serving_PTP_Time_with_NTP">
+<section id="sec-Serving_PTP_Time_with_NTP">
<title>Serving PTP Time with NTP</title>
<para>
The <systemitem class="daemon">ntpd</systemitem> daemon can be configured to distribute the time from the system clock synchronized by <application>ptp4l</application> or <application>phc2sys</application> by using the LOCAL reference clock driver. To prevent <systemitem class="daemon">ntpd</systemitem> from adjusting the system clock, the <filename>ntp.conf</filename> file must not specify any <systemitem class="protocol">NTP</systemitem> servers. The following is a minimal example of <filename>ntp.conf</filename>:
@@ -442,7 +442,7 @@ fudge 127.127.1.0 stratum 0</screen>
</note>
</section>
-<section id="Serving_NTP_Time_with_PTP">
+<section id="sec-Serving_NTP_Time_with_PTP">
<title>Serving NTP Time with PTP</title>
<para>
<systemitem class="protocol">NTP</systemitem> to <systemitem class="protocol">PTP</systemitem> synchronization in the opposite direction is also possible. When <systemitem class="daemon">ntpd</systemitem> is used to synchronize the system clock, <application>ptp4l</application> can be configured with the <option>priority1</option> 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 <systemitem class="protocol">PTP</systemitem>:
@@ -462,7 +462,7 @@ With hardware time stamping, <application>phc2sys</application> needs to be used
</para>
</section>
-<section id="Improving_Accuracy">
+<section id="sec-Improving_Accuracy">
<title>Improving Accuracy</title>
<para>
Test results indicate that disabling the tickless kernel capability can significantly improve the stability of the system clock, and thus improve the <systemitem class="protocol">PTP</systemitem> synchronization accuracy (at the cost of increased power consumption). The kernel tickless mode can be disabled by adding <option>nohz=off</option> to the kernel boot option parameters.
@@ -471,12 +471,12 @@ With hardware time stamping, <application>phc2sys</application> needs to be used
<!-- Topics, Resources -->
- <section id="s1-PTP_additional_resources">
+ <section id="sec-PTP_additional_resources">
<title>Additional Resources</title>
<para>
The following sources of information provide additional resources regarding <systemitem class="protocol">PTP</systemitem> and the <application>ptp4l</application> tools.
</para>
-<section id="s2-PTP-docs-inst">
+<section id="sec-PTP-docs-inst">
<title>Installed Documentation</title>
<itemizedlist>
<listitem>
@@ -498,7 +498,7 @@ With hardware time stamping, <application>phc2sys</application> needs to be used
</itemizedlist>
</section>
-<section id="s2-PTP_useful-websites">
+<section id="sec-PTP_useful-websites">
<title>Useful Websites</title>
<para>
<variablelist>
9 years, 8 months
[system-administrators-guide] markup improvements
by stephenw
commit e624163192a93ef7daa02e690ec1dbe26a07313e
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Wed Jul 30 23:31:05 2014 +0200
markup improvements
en-US/Configuring_NTP_Using_the_chrony_Suite.xml | 47 +++++++++++-----------
1 files changed, 24 insertions(+), 23 deletions(-)
---
diff --git a/en-US/Configuring_NTP_Using_the_chrony_Suite.xml b/en-US/Configuring_NTP_Using_the_chrony_Suite.xml
index 53eaaa6..d4459bc 100644
--- a/en-US/Configuring_NTP_Using_the_chrony_Suite.xml
+++ b/en-US/Configuring_NTP_Using_the_chrony_Suite.xml
@@ -103,7 +103,7 @@ Things <systemitem class="daemon">ntpd</systemitem> can do that <systemitem clas
</listitem>
<listitem>
<para>
- The <systemitem class="protocol">NTP</systemitem> daemon (<systemitem class="daemon">ntpd</systemitem>) 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 <systemitem class="protocol">Autokey</systemitem> protocol, should consider using <systemitem class="daemon">ntpd</systemitem>. <application>Chrony</application> only supports symmetric key authentication using a message authentication code (MAC) with MD5, SHA1 or stronger hash functions, whereas <systemitem class="daemon">ntpd</systemitem> also supports the <systemitem class="protocol">Autokey</systemitem> authentication protocol which can make use of the PKI system. <systemitem class="protocol">Autokey</systemitem> is described in <citetitle pubwork="webpage">RFC5906</citetitle>.
+ The <systemitem class="protocol">NTP</systemitem> daemon (<systemitem class="daemon">ntpd</systemitem>) should be considered for systems which are normally kept permanently on. Systems which are required to use broadcast or multicast <systemitem class="protocol">IP</systemitem>, or to perform authentication of packets with the <systemitem class="protocol">Autokey</systemitem> protocol, should consider using <systemitem class="daemon">ntpd</systemitem>. <application>Chrony</application> only supports symmetric key authentication using a message authentication code (MAC) with MD5, SHA1 or stronger hash functions, whereas <systemitem class="daemon">ntpd</systemitem> also supports the <systemitem class="protocol">Autokey</systemitem> authentication protocol which can make use of the PKI system. <systemitem class="protocol">Autokey</systemitem> is described in <citetitle pubwork="webpage">RFC 5906</citetitle>.
</para>
</listitem>
</itemizedlist>
@@ -121,13 +121,13 @@ Things <systemitem class="daemon">ntpd</systemitem> can do that <systemitem clas
<section id="sect-Understanding_chronyc">
<title>Understanding chronyc</title>
<para>
- The <application>chrony</application> daemon, <systemitem class="daemon">chronyd</systemitem>, can be controlled by the command line utility <application>chronyc</application>. This utility provides a command prompt which allows entering of a number of commands to make changes to <systemitem class="daemon">chronyd</systemitem>. The default configuration is for <systemitem class="daemon">chronyd</systemitem> to only accept commands from a local instance of <application>chronyc</application>, but <application>chronyc</application> can be used to alter the configuration so that <systemitem class="daemon">chronyd</systemitem> will allow external control. That is to say, <application>chronyc</application> can be run remotely after first configuring <systemitem class="daemon">chronyd</systemitem> to accept remote connections. The IP addresses allowed to connect to <systemitem class="daemon">chronyd</systemitem> should be tightly controlled.</para>
+ The <application>chrony</application> daemon, <systemitem class="daemon">chronyd</systemitem>, can be controlled by the command line utility <application>chronyc</application>. This utility provides a command prompt which allows entering of a number of commands to make changes to <systemitem class="daemon">chronyd</systemitem>. The default configuration is for <systemitem class="daemon">chronyd</systemitem> to only accept commands from a local instance of <application>chronyc</application>, but <application>chronyc</application> can be used to alter the configuration so that <systemitem class="daemon">chronyd</systemitem> will allow external control. That is to say, <application>chronyc</application> can be run remotely after first configuring <systemitem class="daemon">chronyd</systemitem> to accept remote connections. The <systemitem class="protocol">IP</systemitem> addresses allowed to connect to <systemitem class="daemon">chronyd</systemitem> should be tightly control
led.</para>
</section>
<section id="sect-Understanding_the_chrony_configuration_commands">
<title>Understanding the chrony Configuration Commands</title>
<para>
- The default configuration file for <systemitem class="daemon">chronyd</systemitem> is <filename>/etc/chrony.conf</filename>. The <option>-f</option> option can be used to specify an alternate configuration file path. Refer to the <systemitem class="daemon">chronyd</systemitem> man page for further options. For a complete list of the directives that can be used see <ulink url="http://chrony.tuxfamily.org/manual.html#Configuration-file"><citetitle pubwork="webpage">http://chrony.tuxfamily.org/manual.html#Configuration-file</citetitle></ulink>. We present here a selection of configuration options:
+ The default configuration file for <systemitem class="daemon">chronyd</systemitem> is <filename>/etc/chrony.conf</filename>. The <option>-f</option> option can be used to specify an alternate configuration file path. See the <systemitem class="daemon">chronyd</systemitem> man page for further options. For a complete list of the directives that can be used see <ulink url="http://chrony.tuxfamily.org/manual.html#Configuration-file"><citetitle pubwork="webpage">http://chrony.tuxfamily.org/manual.html#Configuration-file</citetitle></ulink>. We present here a selection of configuration options:
<variablelist>
<varlistentry>
<term>Comments</term>
@@ -420,7 +420,7 @@ peer w.x.y.z key 10
Were <literal>20</literal> is the key ID and <literal>foobar</literal> is the secret authentication key. The default hash is MD5, and ASCII is the default format for the key.
</para>
<para>
- By default, <systemitem class="daemon">chronyd</systemitem> is configured to listen for commands only from <systemitem class="systemname">localhost</systemitem> (<systemitem class="ipaddress">127.0.0.1</systemitem> and <systemitem class="ipaddress">::1</systemitem>) on port <literal>323</literal>. To access <systemitem class="daemon">chronyd</systemitem> remotely with <application>chronyc</application>, any <command>bindcmdaddress</command> directives in the <filename>/etc/chrony.conf</filename> file should be removed to enable listening on all interfaces and the <command>cmdallow</command> directive should be used to allow commands from the remote IP address, network, or subnet. In addition, port <literal>323</literal> has to be opened in the firewall in order to connect from a remote system. Note that the <command>allow</command> directive is for <systemitem class="protocol">NTP</systemitem> access whereas the <command>cmdallow</command> directive is to enable the
receiving of remote commands. It is possible to make these changes temporarily using <application>chronyc</application> running locally. Edit the configuration file to make persistent changes.
+ By default, <systemitem class="daemon">chronyd</systemitem> is configured to listen for commands only from <systemitem class="systemname">localhost</systemitem> (<systemitem class="ipaddress">127.0.0.1</systemitem> and <systemitem class="ipaddress">::1</systemitem>) on port <literal>323</literal>. To access <systemitem class="daemon">chronyd</systemitem> remotely with <application>chronyc</application>, any <command>bindcmdaddress</command> directives in the <filename>/etc/chrony.conf</filename> file should be removed to enable listening on all interfaces and the <command>cmdallow</command> directive should be used to allow commands from the remote <systemitem class="protocol">IP</systemitem> address, network, or subnet. In addition, port <literal>323</literal> has to be opened in the firewall in order to connect from a remote system. Note that the <command>allow</command> directive is for <systemitem class="protocol">NTP</systemitem> access whereas the <command>cmda
llow</command> directive is to enable the receiving of remote commands. It is possible to make these changes temporarily using <application>chronyc</application> running locally. Edit the configuration file to make persistent changes.
</para>
<para>
The communication between <application>chronyc</application> and <application>chronyd</application> is done over <systemitem class="protocol">UDP</systemitem>, so it needs to be authorized before issuing operational commands. To authorize, use the <command>authhash</command> and <command>password</command> commands as follows:
@@ -485,7 +485,7 @@ chronyc> <command>password HEX:A6CFC50C9C93AB6E5A19754C246242FC5471BCDF</command
<section id="sect-Checking_if_chrony_is_installed">
<title>Checking if chrony is Installed</title>
<para>
- To check if <application>chrony</application> is installed, run the following command as root:
+ To check if <application>chrony</application> is installed, run the following command as <systemitem class="username">root</systemitem>:
<screen>~]# <command>yum install chrony</command></screen>
The default location for the <application>chrony</application> daemon is <filename>/usr/sbin/chronyd</filename>. The command line utility will be installed to <filename>/usr/bin/chronyc</filename>.
</para>
@@ -494,7 +494,7 @@ chronyc> <command>password HEX:A6CFC50C9C93AB6E5A19754C246242FC5471BCDF</command
<section id="sect-Installing_chrony">
<title>Installing chrony</title>
<para>
-To install <application>chrony</application>, run the following command as root:
+To install <application>chrony</application>, run the following command as <systemitem class="username">root</systemitem>:
<screen>~]# <command>yum install chrony -y</command></screen>
The default location for the <application>chrony</application> daemon is <filename>/usr/sbin/chronyd</filename>. The command line utility will be installed to <filename>/usr/bin/chronyc</filename>.
</para>
@@ -514,22 +514,22 @@ chronyd.service - NTP client/server
<section id="sect-Starting_chronyd">
<title>Starting chronyd</title>
<para>
- To start <systemitem class="daemon">chronyd</systemitem>, issue the following command as root:
+ To start <systemitem class="daemon">chronyd</systemitem>, issue the following command as <systemitem class="username">root</systemitem>:
<screen>~]# <command>systemctl start chronyd</command></screen>
</para>
<para>
- To ensure <systemitem class="daemon">chronyd</systemitem> starts automatically at system start, issue the following command as root:
+ To ensure <systemitem class="daemon">chronyd</systemitem> starts automatically at system start, issue the following command as <systemitem class="username">root</systemitem>:
<screen>~]# <command>systemctl enable chronyd</command></screen>
</para>
</section>
<section id="sect-Stopping_chronyd">
<title>Stopping chronyd</title>
<para>
- To stop <systemitem class="daemon">chronyd</systemitem>, issue the following command as root:
+ To stop <systemitem class="daemon">chronyd</systemitem>, issue the following command as <systemitem class="username">root</systemitem>:
<screen>~]# <command>systemctl stop chronyd</command></screen>
</para>
<para>
- To prevent <systemitem class="daemon">chronyd</systemitem> from starting automatically at system start, issue the following command as root:
+ To prevent <systemitem class="daemon">chronyd</systemitem> from starting automatically at system start, issue the following command as <systemitem class="username">root</systemitem>:
<screen>~]# <command>systemctl disable chronyd</command></screen>
</para>
</section>
@@ -568,7 +568,8 @@ Leap status : Normal
<term>Reference ID</term>
<listitem>
<para>
- This is the reference ID and name (or IP address) if available, of the server to which the computer is currently synchronized. If this is <systemitem class="ipaddress">127.127.1.1</systemitem> it means the computer is not synchronized to any external source and that you have the <quote>local</quote> mode operating (via the local command in <application>chronyc</application>, or the <command>local</command> directive in the <filename>/etc/chrony.conf</filename> file (see section <command>local</command>)).</para>
+ This is the reference ID and name (or <systemitem class="protocol">IP</systemitem> address) if available, of the server to which the computer is currently synchronized. If this is <systemitem class="ipaddress">127.127.1.1</systemitem> it means the computer is not synchronized to any external source and that you have the <quote>local</quote> mode operating (via the local command in <application>chronyc</application>, or the <command>local</command> directive in the <filename>/etc/chrony.conf</filename> file (see section <command>local</command>)).
+ </para>
</listitem>
</varlistentry>
@@ -696,7 +697,7 @@ This column indicates the state of the sources. <quote>*</quote> indicates the s
<term>Name/IP address</term>
<listitem>
<para>
-This shows the name or the IP address of the source, or reference ID for reference clocks.
+This shows the name or the <systemitem class="protocol">IP</systemitem> address of the source, or reference ID for reference clocks.
</para>
</listitem>
</varlistentry>
@@ -769,7 +770,7 @@ The columns are as follows:
<term>Name/IP address</term>
<listitem>
<para>
-This is the name or IP address of the <systemitem class="protocol">NTP</systemitem> server (or peer) or reference ID of the reference clock to which the rest of the line relates.
+This is the name or <systemitem class="protocol">IP</systemitem> address of the <systemitem class="protocol">NTP</systemitem> server (or peer) or reference ID of the reference clock to which the rest of the line relates.
</para>
</listitem>
</varlistentry>
@@ -837,7 +838,7 @@ This is the estimated error bounds on Freq (again in parts per million).
<section id="sect-Manually_Adjusting-the-System_Clock">
<title>Manually Adjusting the System Clock</title>
<para>
- To update, or step, the system clock immediately, bypassing any adjustments in progress by slewing the clock, issue the following commands as root:
+ To update, or step, the system clock immediately, bypassing any adjustments in progress by slewing the clock, issue the following commands as <systemitem class="username">root</systemitem>:
<screen>~]# <command>chronyc</command>
chrony> <command>password</command> <replaceable>commandkey-password</replaceable>
200 OK
@@ -874,8 +875,8 @@ The command key ID is generated at install time and should correspond with the <
<orderedlist>
<listitem>
<para>
- Using your editor running as root, add the addresses of four <systemitem class="protocol">NTP</systemitem> servers as follows:
- <screen>
+ Using your editor running as <systemitem class="username">root</systemitem>, add the addresses of four <systemitem class="protocol">NTP</systemitem> servers as follows:
+ <screen>
server 0.pool.ntp.org offline
server 1.pool.ntp.org offline
server 2.pool.ntp.org offline
@@ -894,7 +895,7 @@ The <option>offline</option> option can be useful in preventing systems from try
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> command is used.
</para>
<para>
- On the system selected to be the master, using a text editor running as root, edit the <filename>/etc/chrony.conf</filename> as follows:
+ On the system selected to be the master, using a text editor running as <systemitem class="username">root</systemitem>, edit the <filename>/etc/chrony.conf</filename> as follows:
<screen>
driftfile /var/lib/chrony/drift
commandkey 1
@@ -906,7 +907,7 @@ allow 192.0.2.0
</screen>
Where <systemitem class="ipaddress">192.0.2.0</systemitem> is the network or subnet address from which the clients are allowed to connect.</para>
<para>
- On the systems selected to be direct clients of the master, using a text editor running as root, edit the <filename>/etc/chrony.conf</filename> as follows:
+ On the systems selected to be direct clients of the master, using a text editor running as <systemitem class="username">root</systemitem>, edit the <filename>/etc/chrony.conf</filename> as follows:
<screen>server master
driftfile /var/lib/chrony/drift
logdir /var/log/chrony
@@ -916,7 +917,7 @@ commandkey 24
local stratum 10
initstepslew 20 master
allow 192.0.2.123</screen>
-Where <systemitem class="ipaddress">192.0.2.123</systemitem> is the address of the master, and <systemitem class="systemname">master</systemitem> is the host name of the master. These client will resynchronize the master if it restarts.
+Where <systemitem class="ipaddress">192.0.2.123</systemitem> is the address of the master, and <systemitem class="systemname">master</systemitem> is the host name of the master. Clients with this configuration will resynchronize the master if it restarts.
</para>
<para>
@@ -933,9 +934,9 @@ Where <systemitem class="ipaddress">192.0.2.123</systemitem> is the address of t
<section id="sect-Using_chronyc_chronyc_to_control_chronyd">
<title>Using chronyc to Control chronyd</title>
<para>
- To make changes using the command line utility <application>chronyc</application> in interactive mode, enter the following command as root:
+ To make changes using the command line utility <application>chronyc</application> in interactive mode, enter the following command as <systemitem class="username">root</systemitem>:
<screen>~]# <command>chronyc</command></screen>
- <application>chronyc</application> must run as root if some of the restricted commands are to be used.
+ <application>chronyc</application> must run as <systemitem class="username">root</systemitem> if some of the restricted commands are to be used.
</para>
<para>
The <application>chronyc</application> command prompt will be displayed as follows:</para>
@@ -953,12 +954,12 @@ Where <systemitem class="ipaddress">192.0.2.123</systemitem> is the address of t
<section id="sect-Using_chronyc_for_remote_administration">
<title>Using chronyc for Remote Administration</title>
<para>
-To configure <application>chrony</application> to connect to a remote instance of <systemitem class="daemon">chronyd</systemitem>, issue a command as root in the following format:
+To configure <application>chrony</application> to connect to a remote instance of <systemitem class="daemon">chronyd</systemitem>, issue a command as <systemitem class="username">root</systemitem> in the following format:
<screen>~]# <command>chronyc <option>-h</option> <replaceable>hostname</replaceable></command></screen>
Where <replaceable>hostname</replaceable> is the <systemitem class="systemname">hostname</systemitem> of a system running <systemitem class="daemon">chronyd</systemitem> to connect to in order to allow remote administration from that host. The default is to connect to the daemon on the localhost.
</para>
<para>
-To configure <application>chrony</application> to connect to a remote instance of <systemitem class="daemon">chronyd</systemitem> on a non-default port, issue a command as root in the following format:
+To configure <application>chrony</application> to connect to a remote instance of <systemitem class="daemon">chronyd</systemitem> on a non-default port, issue a command as <systemitem class="username">root</systemitem> in the following format:
<screen>~]# <command>chronyc <option>-h</option> <replaceable>hostname</replaceable> <option>-p</option> <replaceable>port</replaceable></command></screen>
Where <replaceable>port</replaceable> is the port in use for controlling and monitoring by the instance of <systemitem class="daemon">chronyd</systemitem> to be connected to.
</para>
9 years, 8 months
[system-administrators-guide] Putting a space between RFC and the number {for consistency}
by stephenw
commit d66287db33e3a19a6d7146f4575bdda5c561a1a3
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Wed Jul 30 23:29:27 2014 +0200
Putting a space between RFC and the number {for consistency}
en-US/Configuring_NTP_Using_the_chrony_Suite.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/en-US/Configuring_NTP_Using_the_chrony_Suite.xml b/en-US/Configuring_NTP_Using_the_chrony_Suite.xml
index 1068221..53eaaa6 100644
--- a/en-US/Configuring_NTP_Using_the_chrony_Suite.xml
+++ b/en-US/Configuring_NTP_Using_the_chrony_Suite.xml
@@ -82,7 +82,7 @@ Things <systemitem class="daemon">ntpd</systemitem> can do that <systemitem clas
<itemizedlist>
<listitem>
<para>
- <systemitem class="daemon">ntpd</systemitem> fully supports <systemitem class="protocol">NTP</systemitem> version 4 (<citetitle pubwork="webpage">RFC5905</citetitle>), including broadcast, multicast, manycast clients and servers, and the orphan mode. It also supports extra authentication schemes based on public-key cryptography (<citetitle pubwork="webpage">RFC5906</citetitle>). <systemitem class="daemon">chronyd</systemitem> uses <systemitem class="protocol">NTP</systemitem> version 3 (<citetitle pubwork="webpage">RFC1305</citetitle>), which is compatible with version 4.
+ <systemitem class="daemon">ntpd</systemitem> fully supports <systemitem class="protocol">NTP</systemitem> version 4 (<citetitle pubwork="webpage">RFC 5905</citetitle>), including broadcast, multicast, manycast clients and servers, and the orphan mode. It also supports extra authentication schemes based on public-key cryptography (<citetitle pubwork="webpage">RFC 5906</citetitle>). <systemitem class="daemon">chronyd</systemitem> uses <systemitem class="protocol">NTP</systemitem> version 3 (<citetitle pubwork="webpage">RFC 1305</citetitle>), which is compatible with version 4.
</para>
</listitem>
<listitem>
9 years, 8 months
[system-administrators-guide] Putting a space between RFC and the number {for consistency}
by stephenw
commit 33676dff726b351a4dd4583fdc7a262ca15fdf07
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Wed Jul 30 23:14:42 2014 +0200
Putting a space between RFC and the number {for consistency}
en-US/Configuring_NTP_Using_ntpd.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/en-US/Configuring_NTP_Using_ntpd.xml b/en-US/Configuring_NTP_Using_ntpd.xml
index 13a7266..8b36ccd 100644
--- a/en-US/Configuring_NTP_Using_ntpd.xml
+++ b/en-US/Configuring_NTP_Using_ntpd.xml
@@ -161,7 +161,7 @@
<section id="s1-Authentication_Options_for_NTP">
<title>Authentication Options for NTP</title>
<para>
- <systemitem class="protocol">NTPv4</systemitem> 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 <ulink url="http://www.rfc-editor.org/info/rfc5906"><citetitle pubwork="webpage">RFC5906 Network Time Protocol Version 4: Autokey Specification</citetitle></ulink>. The man page <filename>ntp_auth(5)</filename> describes the authentication options and commands for <systemitem class="daemon">ntpd</systemitem>.
+ <systemitem class="protocol">NTPv4</systemitem> 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 <ulink url="http://www.rfc-editor.org/info/rfc5906"><citetitle pubwork="webpage">RFC 5906 Network Time Protocol Version 4: Autokey Specification</citetitle></ulink>. The man page <filename>ntp_auth(5)</filename> describes the authentication options and commands for <systemitem class="daemon">ntpd</systemitem>.
</para>
<para>
An attacker on the network can attempt to disrupt a service by sending <systemitem class="protocol">NTP</systemitem> packets with incorrect time information. On systems using the public pool of <systemitem class="protocol">NTP</systemitem> servers, this risk is mitigated by having more than three <systemitem class="protocol">NTP</systemitem> servers in the list of public <systemitem class="protocol">NTP</systemitem> servers in <filename>/etc/ntp.conf</filename>. If only one time source is compromised or spoofed, <systemitem class="daemon">ntpd</systemitem> will ignore that source. You should conduct a risk assessment and consider the impact of incorrect time on your applications and organization. If you have internal time sources you should consider steps to protect the network over which the <systemitem class="protocol">NTP</systemitem> packets are distributed. If you conduct a risk assessment and conclude that the risk is acceptable, and the impact to your applications
minimal, then you can choose not to use authentication.
9 years, 8 months
[system-administrators-guide] Update ntpd man page list
by stephenw
commit 4c7956fa05a5ee6cfe0c89fda858ce1975109fab
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Tue Jul 29 21:42:02 2014 +0200
Update ntpd man page list
en-US/Configuring_NTP_Using_ntpd.xml | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
---
diff --git a/en-US/Configuring_NTP_Using_ntpd.xml b/en-US/Configuring_NTP_Using_ntpd.xml
index e14507d..13a7266 100644
--- a/en-US/Configuring_NTP_Using_ntpd.xml
+++ b/en-US/Configuring_NTP_Using_ntpd.xml
@@ -801,6 +801,22 @@ In the above example, the kernel is using <application>kvm-clock</application>.
<para>
<filename>ntp_misc(5)</filename> man page — Describes miscellaneous options.</para>
</listitem>
+ <listitem>
+ <para>
+ <filename>ntp_decode(5)</filename> man page — Lists the status words, event messages and error codes used for <systemitem class="service">ntpd</systemitem> reporting and monitoring.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>ntpstat(8)</filename> man page — Describes a utility for reporting the synchronization state of the <systemitem class="protocol">NTP</systemitem> daemon running on the local machine.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>ntptime(8)</filename> man page — Describes a utility for reading and setting kernel time variables.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>tickadj(8)</filename> man page — Describes a utility for reading, and optionally setting, the length of the tick.</para>
+ </listitem>
</itemizedlist>
</section>
9 years, 8 months
[networking-guide] master: Naming Schemes Hierarchy is now a section (94a73f9)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit 94a73f9ccb3abffb1a947d59d558f96c319adfb6
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Tue Jul 29 21:05:49 2014 +0200
Naming Schemes Hierarchy is now a section
incorporate the info from
"Naming Schemes for Network Interfaces"
>---------------------------------------------------------------
en-US/Consistent_Network_Device_Naming.xml | 55 +++++++---------------------
1 files changed, 14 insertions(+), 41 deletions(-)
diff --git a/en-US/Consistent_Network_Device_Naming.xml b/en-US/Consistent_Network_Device_Naming.xml
index 1e75ba5..c509d62 100644
--- a/en-US/Consistent_Network_Device_Naming.xml
+++ b/en-US/Consistent_Network_Device_Naming.xml
@@ -15,75 +15,48 @@
<para>
In &MAJOROSVER;, <systemitem class="daemon">systemd</systemitem> and <application>udev</application> support a number of different naming schemes. The default is to assign fixed names based on firmware, topology, and location information. This has the advantage that the names are fully automatic, fully predictable, that they stay fixed even if hardware is added or removed (no re-enumeration takes place), and that broken hardware can be replaced seamlessly. The disadvantage is that they are sometimes harder to read than the <interface>eth0</interface> or <interface>wlan0</interface> names traditionally used. For example: <interface>enp5s0</interface>.
</para>
- <bridgehead id="bh-Naming_Schemes_for_Network_Interfaces">Naming Schemes for Network Interfaces</bridgehead>
- <para>
- The following different naming schemes for network interfaces are now supported by <application>udev</application> natively:
- <orderedlist>
- <listitem>
- <para>
- Names incorporating Firmware or BIOS provided index numbers for on-board devices (example: <literal>eno1</literal>)
- </para>
- </listitem>
- <listitem>
- <para>
- Names incorporating Firmware or BIOS provided PCI Express hotplug slot index numbers (example: <literal>ens1</literal>)
- </para>
- </listitem>
- <listitem>
- <para>
- Names incorporating physical location of the connector of the hardware (example: <literal>enp2s0</literal>)
- </para>
- </listitem>
- <listitem>
- <para>
- Names incorporating the interface's MAC address (example: <literal>enx78e7d1ea46da</literal>)
- </para>
- </listitem>
- <listitem>
- <para>
- The traditional unpredictable kernel-native <interface>eth<replaceable>X</replaceable></interface> naming (example: <literal>eth0</literal>)
- </para>
- </listitem>
-</orderedlist>
-</para>
-<bridgehead id="bh-Naming_Schemes_Hierarchy">Naming Schemes Hierarchy</bridgehead>
-<para>
-By default, <systemitem class="daemon">systemd</systemitem> will name interfaces using the following policy to apply the naming schemes listed above :
+
+<section id="sec-Naming_Schemes_Hierarchy">
+<title>Naming Schemes Hierarchy</title>
+
+ <para>
+ By default, <systemitem class="daemon">systemd</systemitem> will name interfaces using the following policy to apply the supported naming schemes:
<itemizedlist>
<listitem>
<para>
- <emphasis role="bold">Scheme 1:</emphasis> Names incorporating Firmware or BIOS provided index numbers for on-board devices (example: <literal>eno1</literal>), are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 2;
+ <emphasis role="bold">Scheme 1:</emphasis> Names incorporating Firmware or BIOS provided index numbers for on-board devices (example: <literal>eno1</literal>), are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 2.
</para>
</listitem>
<listitem>
<para>
- <emphasis role="bold">Scheme 2:</emphasis> Names incorporating Firmware or BIOS provided PCI Express hotplug slot index numbers (example: <literal>ens1</literal>) are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 3;
+ <emphasis role="bold">Scheme 2:</emphasis> Names incorporating Firmware or BIOS provided PCI Express hotplug slot index numbers (example: <literal>ens1</literal>) are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 3.
</para>
</listitem>
<listitem>
<para>
- <emphasis role="bold">Scheme 3:</emphasis> Names incorporating physical location of the connector of the hardware (example: <literal>enp2s0</literal>), are applied if applicable, else falling directly back to scheme 5 in all other cases;
+ <emphasis role="bold">Scheme 3:</emphasis> Names incorporating physical location of the connector of the hardware (example: <literal>enp2s0</literal>), are applied if applicable, else falling directly back to scheme 5 in all other cases.
</para>
</listitem>
<listitem>
<para>
- <emphasis role="bold">Scheme 4:</emphasis> Names incorporating interface's MAC address, is not used by default, but is available if the user chooses;
+ <emphasis role="bold">Scheme 4:</emphasis> Names incorporating interface's MAC address (example: <literal>enx78e7d1ea46da</literal>), is not used by default, but is available if the user chooses.
</para>
</listitem>
<listitem>
<para>
- <emphasis role="bold">Scheme 5:</emphasis> The traditional unpredictable kernel naming scheme, is used if all other methods fail.
+ <emphasis role="bold">Scheme 5:</emphasis> The traditional unpredictable kernel naming scheme, is used if all other methods fail (example: <literal>eth0</literal>).
</para>
</listitem>
-
</itemizedlist>
-
</para>
+
<para>
This policy, the procedure outlined above, is the default. If the system has <application>biosdevname</application> enabled, it will take precedence. Note that enabling <application>biosdevname</application> requires passing <command>biosdevname=1</command> as a command line parameter except in the case of a Dell system, where <application>biosdevname</application> will be used by default as long as it is installed. If the user has added <application>udev</application> rules which change the name of the kernel devices, those rules will take precedence too.
</para>
+ </section>
+
<section id="sec-Understanding_the_Device_Renaming_Procedure">
<title>Understanding the Device Renaming Procedure</title>
<para>
9 years, 8 months
[networking-guide] master: Adding: Using Channel Bonding (7d3ceba)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit 7d3ceba1922f843919e3b0af7171992d2170b53d
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Tue Jul 29 09:34:15 2014 +0200
Adding: Using Channel Bonding
moved here from the SysAdmin Guide
>---------------------------------------------------------------
en-US/Configure_Network_Bonding.xml | 384 +++++++++++++++++++++++++++++++++++
1 files changed, 384 insertions(+), 0 deletions(-)
diff --git a/en-US/Configure_Network_Bonding.xml b/en-US/Configure_Network_Bonding.xml
index bf00546..08b4e94 100644
--- a/en-US/Configure_Network_Bonding.xml
+++ b/en-US/Configure_Network_Bonding.xml
@@ -401,6 +401,390 @@ NM_CONTROLLED=no</programlisting>
</section>
+ <section
+ id="sec-Using_Channel_Bonding">
+ <title>Using Channel Bonding</title>
+ <indexterm>
+ <primary>kernel module</primary>
+ <secondary>bonding module</secondary>
+ <tertiary>description</tertiary>
+ </indexterm>
+ <indexterm>
+ <primary>channel bonding</primary>
+ <secondary>description</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>bonding</primary>
+ <see>channel bonding</see>
+ </indexterm>
+ <indexterm>
+ <primary>NIC</primary>
+ <secondary>binding into single channel</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>channel bonding interface</primary>
+ <see>kernel module</see>
+ </indexterm>
+
+ <indexterm>
+ <primary>kernel module</primary>
+ <secondary>bonding module</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>channel bonding</primary>
+ <secondary>configuration</secondary>
+ </indexterm>
+
+ <para>To enhance performance, adjust available module options to ascertain what combination works best. Pay particular attention to the <command>miimon</command> or <command>arp_interval</command> and the <command>arp_ip_target</command> parameters. See <xref
+ linkend="s3-modules-bonding-directives"/> for a list of available options and how to quickly determine the best ones for your bonded interface.</para>
+
+ <section
+ id="s3-modules-bonding-directives">
+ <title>Bonding Module Directives</title>
+ <indexterm>
+ <primary>kernel module</primary>
+ <secondary>bonding module</secondary>
+ <tertiary>parameters to bonded interfaces</tertiary>
+ </indexterm>
+ <indexterm>
+ <primary>kernel module</primary>
+ <secondary>module parameters</secondary>
+ <tertiary>bonding module parameters</tertiary>
+ </indexterm>
+ <indexterm>
+ <primary>channel bonding</primary>
+ <secondary>parameters to bonded interfaces</secondary>
+ </indexterm>
+ <para>It is a good idea to test which channel bonding module parameters work best for your bonded interfaces before adding them to the <parameter
+ class="option">BONDING_OPTS="<replaceable><bonding parameters></replaceable>"</parameter> directive in your bonding interface configuration file (<filename>ifcfg-bond0</filename> for example). Parameters to bonded interfaces can be configured without unloading (and reloading) the bonding module by manipulating files in the <systemitem
+ class="filesystem">sysfs</systemitem> file system.</para>
+ <para>
+ <systemitem
+ class="filesystem">sysfs</systemitem> is a virtual file system that represents kernel objects as directories, files and symbolic links. <systemitem
+ class="filesystem">sysfs</systemitem> can be used to query for information about kernel objects, and can also manipulate those objects through the use of normal file system commands. The <systemitem
+ class="filesystem">sysfs</systemitem> virtual file system is mounted under the <filename>/sys/</filename> directory. All bonding interfaces can be configured dynamically by interacting with and manipulating files under the <filename>/sys/class/net/</filename> directory. </para>
+ <para>In order to determine the best parameters for your bonding interface, create a channel bonding interface file such as <filename>ifcfg-bond0</filename> by following the instructions in <xref linkend="sec-Create_a_Channel_Bonding_Interface" />. Insert the <parameter
+ class="option">SLAVE=yes</parameter> and <parameter
+ class="option">MASTER=bond0</parameter> directives in the configuration files for each interface bonded to bond0. Once this is completed, you can proceed to testing the parameters.</para>
+ <para>First, bring up the bond you created by running <command>/usr/sbin/ifup <option>bond<replaceable><N></replaceable></option></command> as <systemitem class="username">root</systemitem>:</para>
+ <screen>~]# <command>/usr/sbin/ifup bond0</command></screen>
+ <para>If you have correctly created the <filename>ifcfg-bond0</filename> bonding interface file, you will be able to see <computeroutput>bond0</computeroutput> listed in the output of running <command>ifconfig</command> (without any options):</para>
+ <screen>~]# <command>ifconfig</command>
+bond0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
+ UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
+ RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+ TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+ collisions:0 txqueuelen:0
+ RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
+eth0 Link encap:Ethernet HWaddr 52:54:00:26:9E:F1
+ inet addr:192.168.122.251 Bcast:192.168.122.255 Mask:255.255.255.0
+ inet6 addr: fe80::5054:ff:fe26:9ef1/64 Scope:Link
+ UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
+ RX packets:207 errors:0 dropped:0 overruns:0 frame:0
+ TX packets:205 errors:0 dropped:0 overruns:0 carrier:0
+ collisions:0 txqueuelen:1000
+ RX bytes:70374 (68.7 KiB) TX bytes:25298 (24.7 KiB)
+<lineannotation>[output truncated]</lineannotation>
+ </screen>
+ <para>To view all existing bonds, even if they are not up, run:</para>
+ <screen>~]# <command>cat /sys/class/net/bonding_masters</command>
+bond0</screen>
+ <para>You can configure each bond individually by manipulating the files located in the <filename>/sys/class/net/bond<replaceable><N></replaceable>/bonding/</filename> directory. First, the bond you are configuring must be taken down:</para>
+ <screen>~]# <command>/usr/sbin/ifdown bond0</command>
+ </screen>
+ <para>As an example, to enable MII monitoring on bond0 with a 1 second interval, run as <systemitem class="username">root</systemitem>:</para>
+ <screen>~]# <command>echo 1000 > /sys/class/net/bond0/bonding/miimon</command>
+ </screen>
+ <para>To configure bond0 for <parameter
+ class="option">balance-alb</parameter> mode, run either:</para>
+ <screen>~]# <command>echo 6 > /sys/class/net/bond0/bonding/mode</command>
+ </screen>
+ <para>...or, using the name of the mode:</para>
+ <screen>~]# <command>echo balance-alb > /sys/class/net/bond0/bonding/mode</command>
+ </screen>
+ <para>After configuring options for the bond in question, you can bring it up and test it by running <command>/usr/sbin/ifup bond<replaceable><N></replaceable></command>. If you decide to change the options, take the interface down, modify its parameters using <systemitem class="filesystem">sysfs</systemitem>, bring it back up, and re-test.</para>
+ <para>Once you have determined the best set of parameters for your bond, add those parameters as a space-separated list to the <parameter
+ class="option">BONDING_OPTS=</parameter> directive of the <filename>/etc/sysconfig/network-scripts/ifcfg-bond<replaceable><N></replaceable>
+ </filename> file for the bonding interface you are configuring. Whenever that bond is brought up (for example, by the system during the boot sequence if the <parameter
+ class="option">ONBOOT=yes</parameter> directive is set), the bonding options specified in the <parameter
+ class="option">BONDING_OPTS</parameter> will take effect for that bond.</para>
+ <para>The following list provides the names of many of the more common channel bonding parameters, along with a description of what they do. For more information, see the brief descriptions for each <computeroutput>parm</computeroutput> in <command>modinfo bonding</command> output, or for more detailed information, see <ulink url="https://www.kernel.org/doc/Documentation/networking/bonding.txt">https://www.kernel.org/doc/Documentation/networking/bonding.txt</ulink><!--the <filename>bonding.txt</filename> file in the <package>kernel-doc</package> package (see <xref
+ linkend="s1-kernel-modules-additional-resources"/>)-->.</para>
+ <variablelist
+ spacing="compact">
+ <title>Bonding Interface Parameters</title>
+ <varlistentry>
+ <term>
+ <literal>arp_interval=<replaceable><time_in_milliseconds></replaceable>
+ </literal>
+ </term>
+ <listitem>
+ <para>Specifies, in milliseconds, how often <systemitem class="protocol">ARP</systemitem> monitoring occurs.</para>
+ <important>
+ <!-- <title>Make sure you specify all required parameters</title> -->
+ <para>It is essential that both <literal>arp_interval</literal> and <literal>arp_ip_target</literal> parameters are specified, or, alternatively, the <literal>miimon</literal> parameter is specified. Failure to do so can cause degradation of network performance in the event that a link fails.</para>
+ </important>
+ <para>If using this setting while in <literal>mode=0</literal> or <literal>mode=1</literal> (the two load-balancing modes), the network switch must be configured to distribute packets evenly across the NICs. For more information on how to accomplish this, see <ulink url="https://www.kernel.org/doc/Documentation/networking/bonding.txt">https://www.kernel.org/doc/Documentation/networking/bonding.txt</ulink><!--<filename>/usr/share/doc/kernel-doc-<replaceable><kernel_version></replaceable>/Documentation/networking/bonding.txt</filename>-->.
+ </para>
+ <para>The value is set to <userinput>0</userinput> by default, which disables it.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>arp_ip_target=<replaceable><ip_address></replaceable><optional>,<replaceable><ip_address_2></replaceable>,…<replaceable><ip_address_16></replaceable></optional>
+ </literal>
+ </term>
+ <listitem>
+ <para>Specifies the target <systemitem class="protocol">IP</systemitem> address of <systemitem class="protocol">ARP</systemitem> requests when the <literal>arp_interval</literal> parameter is enabled. Up to 16 <systemitem class="protocol">IP</systemitem> addresses can be specified in a comma separated list.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>arp_validate=<replaceable><value></replaceable>
+ </literal>
+ </term>
+ <listitem>
+ <para>Validate source/distribution of <systemitem class="protocol">ARP</systemitem> probes; default is <userinput>none</userinput>. Other valid values are <userinput>active</userinput>, <userinput>backup</userinput>, and <userinput>all</userinput>.</para>
+ </listitem>
+ </varlistentry>
+ <!-- <varlistentry>
+ <term>
+ <literal>debug=<replaceable><number></replaceable>
+ </literal>
+ </term>
+ <listitem>
+ <para>Enables debug messages. Possible values are:</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <userinput>0</userinput> — Debug messages are disabled. This is the default.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <userinput>1</userinput> — Debug messages are enabled.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </varlistentry> -->
+ <varlistentry>
+ <term>
+ <literal>downdelay=<replaceable><time_in_milliseconds></replaceable>
+ </literal>
+ </term>
+ <listitem>
+ <para>Specifies (in milliseconds) how long to wait after link failure before disabling the link. The value must be a multiple of the value specified in the <literal>miimon</literal> parameter. The value is set to <userinput>0</userinput> by default, which disables it.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>lacp_rate=<replaceable><value></replaceable>
+ </term>
+ <listitem>
+ <para>Specifies the rate at which link partners should transmit LACPDU packets in 802.3ad mode. Possible values are:</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <userinput>slow</userinput> or <userinput>0</userinput> — Default setting. This specifies that partners should transmit LACPDUs every 30 seconds.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <userinput>fast</userinput> or <userinput>1</userinput> — Specifies that partners should transmit LACPDUs every 1 second.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>miimon=<replaceable><time_in_milliseconds></replaceable>
+ </literal>
+ </term>
+ <listitem>
+ <para>Specifies (in milliseconds) how often MII link monitoring occurs. This is useful if high availability is required because MII is used to verify that the NIC is active. To verify that the driver for a particular NIC supports the MII tool, type the following command as root:</para>
+ <screen>~]# <command>ethtool <replaceable><interface_name></replaceable> | grep "Link detected:"</command>
+ </screen>
+ <para>In this command, replace <replaceable><interface_name</replaceable>> with the name of the device interface, such as <userinput>eth0</userinput>, not the bond interface. If MII is supported, the command returns:</para>
+ <screen>Link detected: yes</screen>
+ <para>If using a bonded interface for high availability, the module for each NIC must support MII. Setting the value to <userinput>0</userinput> (the default), turns this feature off. When configuring this setting, a good starting point for this parameter is <userinput>100</userinput>.</para>
+ <important>
+ <!-- <title>Make sure you specify all required parameters</title> -->
+ <para>It is essential that both <literal>arp_interval</literal> and <literal>arp_ip_target</literal> parameters are specified, or, alternatively, the <literal>miimon</literal> parameter is specified. Failure to do so can cause degradation of network performance in the event that a link fails.</para>
+ </important>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>mode=<replaceable><value></replaceable>
+ </literal>
+ </term>
+ <listitem>
+ <para>Allows you to specify the bonding policy. The <replaceable><value></replaceable> can be one of:</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <userinput>balance-rr</userinput> or <userinput>0</userinput> — Sets a round-robin policy for fault tolerance and load balancing. Transmissions are received and sent out sequentially on each bonded slave interface beginning with the first one available.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <userinput>active-backup</userinput> or <userinput>1</userinput> — Sets an active-backup policy for fault tolerance. Transmissions are received and sent out via the first available bonded slave interface. Another bonded slave interface is only used if the active bonded slave interface fails.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <userinput>balance-xor</userinput> or <userinput>2</userinput> — Transmissions are based on the selected hash policy. The default is to derive a hash by XOR of the source and destination MAC addresses multiplied by the modulo of the number of slave interfaces. In this mode traffic destined for specific peers will always be sent over the same interface. As the destination is determined by the MAC addresses this method works best for traffic to peers on the same link or local network. If traffic has to pass through a single router then this mode of traffic balancing will be suboptimal.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <userinput>broadcast</userinput> or <userinput>3</userinput> — Sets a broadcast policy for fault tolerance. All transmissions are sent on all slave interfaces.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <userinput>802.3ad</userinput> or <userinput>4</userinput> — Sets an IEEE 802.3ad dynamic link aggregation policy. Creates aggregation groups that share the same speed and duplex settings. Transmits and receives on all slaves in the active aggregator. Requires a switch that is 802.3ad compliant.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <userinput>balance-tlb</userinput> or <userinput>5</userinput> — Sets a Transmit Load Balancing (TLB) policy for fault tolerance and load balancing. The outgoing traffic is distributed according to the current load on each slave interface. Incoming traffic is received by the current slave. If the receiving slave fails, another slave takes over the MAC address of the failed slave. This mode is only suitable for local addresses known to the kernel bonding module and therefore cannot be used behind a bridge with virtual machines.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <userinput>balance-alb</userinput> or <userinput>6</userinput> — Sets an Adaptive Load Balancing (ALB) policy for fault tolerance and load balancing. Includes transmit and receive load balancing for <systemitem class="protocol">IPv4</systemitem> traffic. Receive load balancing is achieved through <systemitem class="protocol">ARP</systemitem> negotiation. This mode is only suitable for local addresses known to the kernel bonding module and therefore cannot be used behind a bridge with virtual machines.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>num_unsol_na=<replaceable><number></replaceable>
+ </literal>
+ </term>
+ <listitem>
+ <para>Specifies the number of unsolicited <systemitem class="protocol">IPv6</systemitem> Neighbor Advertisements to be issued after a failover event. One unsolicited NA is issued immediately after the failover.</para>
+ <para>The valid range is <userinput>0 - 255</userinput>; the default value is <userinput>1</userinput>. This parameter affects only the active-backup mode.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>primary=<replaceable><interface_name></replaceable>
+ </literal>
+ </term>
+ <listitem>
+ <para>Specifies the interface name, such as <userinput>eth0</userinput>, of the primary device. The <literal>primary</literal> device is the first of the bonding interfaces to be used and is not abandoned unless it fails. This setting is particularly useful when one NIC in the bonding interface is faster and, therefore, able to handle a bigger load.</para>
+ <para>This setting is only valid when the bonding interface is in <userinput>active-backup</userinput> mode. See <ulink url="https://www.kernel.org/doc/Documentation/networking/bonding.txt">https://www.kernel.org/doc/Documentation/networking/bonding.txt</ulink><!--<filename> /usr/share/doc/kernel-doc-<replaceable><kernel-version></replaceable>/Documentation/networking/bonding.txt</filename>--> for more information.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>primary_reselect=<replaceable><value></replaceable>
+ </literal>
+ </term>
+ <listitem>
+ <para>Specifies the reselection policy for the primary slave. This affects how the primary slave is chosen to become the active slave when failure of the active slave or recovery of the primary slave occurs. This parameter is designed to prevent flip-flopping between the primary slave and other slaves. Possible values are:</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <userinput>always</userinput> or <userinput>0</userinput> (default) — The primary slave becomes the active slave whenever it comes back up.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <userinput>better</userinput> or <userinput>1</userinput> — The primary slave becomes the active slave when it comes back up, if the speed and duplex of the primary slave is better than the speed and duplex of the current active slave.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <userinput>failure</userinput> or <userinput>2</userinput> — The primary slave becomes the active slave only if the current active slave fails and the primary slave is up.</para>
+ </listitem>
+ </itemizedlist>
+ <para>The <literal>primary_reselect</literal> setting is ignored in two cases:</para>
+ <itemizedlist>
+ <listitem>
+ <para>If no slaves are active, the first slave to recover is made the active slave.</para>
+ </listitem>
+ <listitem>
+ <para>When initially enslaved, the primary slave is always made the active slave.</para>
+ </listitem>
+ </itemizedlist>
+ <!-- <para>If no slaves are active, the first slave to recover is made the active slave.</para>
+ <para>When initially enslaved, the primary slave is always made the active slave.</para>-->
+ <para>Changing the <literal>primary_reselect</literal> policy via <systemitem
+ class="filesystem">sysfs</systemitem> will cause an immediate selection of the best active slave according to the new policy. This may or may not result in a change of the active slave, depending upon the circumstances</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>updelay=<replaceable><time_in_milliseconds></replaceable>
+ </literal>
+ </term>
+ <listitem>
+ <para>Specifies (in milliseconds) how long to wait before enabling a link. The value must be a multiple of the value specified in the <literal>miimon</literal> parameter. The value is set to <userinput>0</userinput> by default, which disables it.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>use_carrier=<replaceable><number></replaceable>
+ </literal>
+ </term>
+ <listitem>
+ <para>Specifies whether or not <literal>miimon</literal> should use MII/ETHTOOL ioctls or <function>netif_carrier_ok()</function> to determine the link state. The <function>netif_carrier_ok()</function> function relies on the device driver to maintains its state with <literal>netif_carrier_<replaceable>on/off</replaceable></literal>; most device drivers support this function.</para>
+ <para>The MII/ETHTOOL ioctls tools utilize a deprecated calling sequence within the kernel. However, this is still configurable in case your device driver does not support <literal>netif_carrier_<replaceable>on/off</replaceable></literal>.</para>
+ <para>Valid values are:</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <userinput>1</userinput> — Default setting. Enables the use of <function>netif_carrier_ok()</function>.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <userinput>0</userinput> — Enables the use of MII/ETHTOOL ioctls.</para>
+ </listitem>
+ </itemizedlist>
+ <note>
+ <para>If the bonding interface insists that the link is up when it should not be, it is possible that your network device driver does not support <literal>netif_carrier_<replaceable>on/off</replaceable></literal>.</para>
+ </note>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>xmit_hash_policy=<replaceable><value></replaceable>
+ </literal>
+ </term>
+ <listitem>
+ <para>Selects the transmit hash policy used for slave selection in <userinput>balance-xor</userinput> and <userinput>802.3ad</userinput> modes. Possible values are:</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <userinput>0</userinput> or <userinput>layer2</userinput> — Default setting. This parameter uses the XOR of hardware MAC addresses to generate the hash. The formula used is:</para>
+ <screen>(<replaceable><source_MAC_address></replaceable> XOR <replaceable><destination_MAC></replaceable>) MODULO <replaceable><slave_count></replaceable>
+ </screen>
+ <para>This algorithm will place all traffic to a particular network peer on the same slave, and is 802.3ad compliant.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <userinput>1</userinput> or <userinput>layer3+4</userinput> — Uses upper layer protocol information (when available) to generate the hash. This allows for traffic to a particular network peer to span multiple slaves, although a single connection will not span multiple slaves.</para>
+ <para>The formula for unfragmented TCP and UDP packets used is:</para>
+ <screen>((<replaceable><source_port></replaceable> XOR <replaceable><dest_port></replaceable>) XOR
+ ((<replaceable><source_IP></replaceable> XOR <replaceable><dest_IP></replaceable>) AND <constant>0xffff</constant>)
+ MODULO <replaceable><slave_count></replaceable>
+ </screen>
+ <para>For fragmented TCP or UDP packets and all other <systemitem class="protocol">IP</systemitem> protocol traffic, the source and destination port information is omitted. For non-<systemitem class="protocol">IP</systemitem> traffic, the formula is the same as the <command>layer2</command> transmit hash policy.</para>
+ <para>This policy intends to mimic the behavior of certain switches; particularly, Cisco switches with PFC2 as well as some Foundry and IBM products.</para>
+ <para>The algorithm used by this policy is not 802.3ad compliant.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <userinput>2</userinput> or <userinput>layer2+3</userinput> — Uses a combination of layer2 and layer3 protocol information to generate the hash.</para>
+ <para>Uses XOR of hardware MAC addresses and <systemitem class="protocol">IP</systemitem> addresses to generate the hash. The formula is:</para>
+ <screen>(((<replaceable><source_IP></replaceable> XOR <replaceable><dest_IP></replaceable>) AND <constant>0xffff</constant>) XOR
+ ( <replaceable><source_MAC></replaceable> XOR <replaceable><destination_MAC></replaceable> ))
+ MODULO <replaceable><slave_count></replaceable>
+ </screen>
+ <para>This algorithm will place all traffic to a particular network peer on the same slave. For non-<systemitem class="protocol">IP</systemitem> traffic, the formula is the same as for the layer2 transmit hash policy.</para>
+ <para>This policy is intended to provide a more balanced distribution of traffic than layer2 alone, especially in environments where a layer3 gateway device is required to reach most destinations.</para>
+ <para>This algorithm is 802.3ad compliant.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </section>
+ </section>
+
+
<section id="sec-Network_Bonding_Using_the_NetworkManager_Command_Line_Tool_nmcli">
<title>Using the NetworkManager Command Line Tool, nmcli</title>
<para>
9 years, 8 months
[system-administrators-guide] Remove section tag
by stephenw
commit 1a8aaa6a0d878fc8a49c6d56c2bad0db5178ea6c
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Tue Jul 29 09:19:13 2014 +0200
Remove section tag
en-US/Working_with_Kernel_Modules.xml | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
---
diff --git a/en-US/Working_with_Kernel_Modules.xml b/en-US/Working_with_Kernel_Modules.xml
index 800b813..6151f7f 100644
--- a/en-US/Working_with_Kernel_Modules.xml
+++ b/en-US/Working_with_Kernel_Modules.xml
@@ -482,7 +482,6 @@ fi</programlisting>
</note>-->
</section>
- </section>
<section
id="s1-kernel-modules-additional-resources">
<title>Additional Resources</title>
9 years, 8 months
[system-administrators-guide] refer to >> see
by stephenw
commit 6255556ba3f5b38e5fc4a9594f59ed9ed29fd5ec
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Tue Jul 29 09:08:06 2014 +0200
refer to >> see
en-US/Working_with_Kernel_Modules.xml | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
---
diff --git a/en-US/Working_with_Kernel_Modules.xml b/en-US/Working_with_Kernel_Modules.xml
index 6988ab4..800b813 100644
--- a/en-US/Working_with_Kernel_Modules.xml
+++ b/en-US/Working_with_Kernel_Modules.xml
@@ -46,7 +46,7 @@
<para>In order to use the kernel module utilities described in this chapter, first ensure the <package>kmod</package> package is installed on your system by running, as root:</para>
<screen>~]# <command>yum install kmod</command>
</screen>
- <para>For more information on installing packages with Yum, refer to <xref
+ <para>For more information on installing packages with Yum, see <xref
linkend="sec-Installing"/>.</para>
</note>
<section
@@ -112,7 +112,7 @@ kvm 253162 1 kvm_intel
<para>the amount of memory it uses; and,</para>
</listitem>
<listitem>
- <para>the sum total of processes that are using the module and other modules which depend on it, followed by a list of the names of those modules, if there are any. Using this list, you can first unload all the modules depending the module you want to unload. For more information, refer to <xref
+ <para>the sum total of processes that are using the module and other modules which depend on it, followed by a list of the names of those modules, if there are any. Using this list, you can first unload all the modules depending the module you want to unload. For more information, see <xref
linkend="sec-Unloading_a_Module"/>.</para>
</listitem>
</itemizedlist>
@@ -336,7 +336,7 @@ insmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/fcoe/fcoe.ko</scree
class="resource">wacom</systemitem>, through the dependency tree, depends on indirectly.</para>
</listitem>
</itemizedlist>
- <para>Refer to <xref linkend="sec-Listing_Currently-Loaded_Modules"/> for more information about using <command>lsmod</command> to obtain the names of the modules which are preventing you from unloading a certain module.</para>
+ <para>See <xref linkend="sec-Listing_Currently-Loaded_Modules"/> for more information about using <command>lsmod</command> to obtain the names of the modules which are preventing you from unloading a certain module.</para>
<example id="ex-unloading_a_kernel_module">
<title>Unloading a kernel module</title>
<para>For example, if you want to unload the <systemitem class="resource">firewire_ohci</systemitem> module (because you believe there is a bug in it that is affecting system stability, for example), your terminal session might look similar to this:</para>
@@ -430,7 +430,7 @@ rmmod /lib/modules/2.6.32-71.el6.x86_64/kernel/lib/crc-itu-t.ko</screen>
</step>
<step
id="proc-step2-Loading_a_Kernel_Module_with_Custom_Parameters">
- <para>Load the module and list all custom parameters after the module name. For example, if you wanted to load the Intel PRO/1000 network driver with the interrupt throttle rate set to 3000 interrupts per second for the first, second and third instances of the driver, and Energy Efficient Ethernet (EEE) turned on<footnote
+ <para>Load the module and list all custom parameters after the module name. For example, if you wanted to load the Intel PRO/1000 network driver with the interrupt throttle rate set to 3000 interrupts per second for the first, second and third instances of the driver, and Energy Efficient Ethernet (EEE) turned on<footnote
id="footnote-Energy_Efficient_Ethernet"><para>Despite what the example might imply, Energy Efficient Ethernet is turned on by default in the <systemitem
class="resource">e1000e</systemitem> driver.</para>
</footnote>
@@ -486,7 +486,7 @@ fi</programlisting>
<section
id="s1-kernel-modules-additional-resources">
<title>Additional Resources</title>
- <para>For more information on kernel modules and their utilities, refer to the following resources.</para>
+ <para>For more information on kernel modules and their utilities, see the following resources.</para>
<section id="s2-kernel-modules-additional-resources-installed">
<title>Installed Documentation</title>
<para>There are a number of manual pages for various utilities related to kernel modules:</para>
@@ -556,7 +556,7 @@ fi</programlisting>
<section
id="sec-Setting_Module_Parameters">
<title>Setting Module Parameters</title>
- <para>This section lists modules used for a common hardware, and their respective parameters. Refer to <xref
+ <para>This section lists modules used for a common hardware, and their respective parameters. See <xref
linkend="s2-kernel-module-utils-modprobe" /> for information on how to load them to the running kernel, and <xref
linkend="s2-kernel-modules-persistent" /> for instructions on how to load them automatically at boot time. Note that to view parameters for a certain module, you can use the <command>modinfo</command> command as described in <xref
linkend="sec-Displaying_Information_About_a_Module" />.</para>
@@ -856,7 +856,7 @@ fi</programlisting>
<primary>kernel module</primary>
<secondary>NIC module</secondary>
</indexterm>
- <para>The preferred way to configure most modern Ethernet-based network interface cards (NICs) is to use <command>ethtool</command> or <command>mii-tool</command>. Only after these tools fail to work should module parameters be adjusted. Refer to manual pages for <command>ethtool</command> and <command>mii-tool</command> for more information on their usage.</para>
+ <para>The preferred way to configure most modern Ethernet-based network interface cards (NICs) is to use <command>ethtool</command> or <command>mii-tool</command>. Only after these tools fail to work should module parameters be adjusted. See manual pages for <command>ethtool</command> and <command>mii-tool</command> for more information on their usage.</para>
<table
id="tb-modules-ethernet">
<title>Ethernet Module Parameters</title>
9 years, 8 months
[system-administrators-guide] style, markup, and typos
by stephenw
commit d866b4c6859e014c502e97bf74163d35a0c6bdcb
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Tue Jul 29 09:05:37 2014 +0200
style, markup, and typos
en-US/Working_with_Kernel_Modules.xml | 69 +++++++++-----------------------
1 files changed, 20 insertions(+), 49 deletions(-)
---
diff --git a/en-US/Working_with_Kernel_Modules.xml b/en-US/Working_with_Kernel_Modules.xml
index e552be6..6988ab4 100644
--- a/en-US/Working_with_Kernel_Modules.xml
+++ b/en-US/Working_with_Kernel_Modules.xml
@@ -60,14 +60,10 @@
<indexterm>
<primary>kernel module</primary>
<secondary>utilities</secondary>
- <tertiary>
- <command>lsmod</command>
- </tertiary>
+ <tertiary><command>lsmod</command></tertiary>
</indexterm>
<indexterm>
- <primary>
- <command>lsmod</command>
- </primary>
+ <primary><command>lsmod</command></primary>
<seealso>kernel module</seealso>
</indexterm>
<para>You can list all kernel modules that are currently loaded into the kernel by running the <command>lsmod</command> command, for example:</para>
@@ -123,9 +119,7 @@ kvm 253162 1 kvm_intel
<indexterm>
<primary>kernel module</primary>
<secondary>files</secondary>
- <tertiary>
- <filename>/proc/modules</filename>
- </tertiary>
+ <tertiary><filename>/proc/modules</filename></tertiary>
</indexterm>
<para>Finally, note that <command>lsmod</command> output is less verbose and considerably easier to read than the content of the <filename>/proc/modules</filename> pseudo-file.</para>
</section>
@@ -140,14 +134,10 @@ kvm 253162 1 kvm_intel
<indexterm>
<primary>kernel module</primary>
<secondary>utilities</secondary>
- <tertiary>
- <command>modinfo</command>
- </tertiary>
+ <tertiary><command>modinfo</command></tertiary>
</indexterm>
<indexterm>
- <primary>
- <command>modinfo</command>
- </primary>
+ <primary><command>modinfo</command></primary>
<seealso>kernel module</seealso>
</indexterm>
<para>You can display detailed information about a kernel module by running the <command>modinfo <replaceable>module_name</replaceable></command> command.</para>
@@ -264,14 +254,10 @@ parm: WriteProtectNVM:Write-protect NVM [WARNING: disabling this can l
<indexterm>
<primary>kernel module</primary>
<secondary>utilities</secondary>
- <tertiary>
- <command>modprobe</command>
- </tertiary>
+ <tertiary><command>modprobe</command></tertiary>
</indexterm>
<indexterm>
- <primary>
- <command>modprobe</command>
- </primary>
+ <primary><command>modprobe</command></primary>
<seealso>kernel module</seealso>
</indexterm>
<para>To load a kernel module, run <command>modprobe <replaceable>module_name</replaceable></command> as <systemitem class="username">root</systemitem>. For example, to load the <systemitem class="resource">wacom</systemitem> module, run:</para>
@@ -285,10 +271,10 @@ parm: WriteProtectNVM:Write-protect NVM [WARNING: disabling this can l
class="directory">/lib/modules/<replaceable>kernel_version</replaceable>/kernel/drivers/</filename>
</tertiary>
</indexterm>
- <para>By default, <command>modprobe</command> attempts to load the module from <filename class="directory">/lib/modules/<replaceable>kernel_version</replaceable>/kernel/drivers/</filename>. In this directory, each type of module has its own subdirectory, such as <filename class="directory">net/</filename> and <filename class="directory">scsi/</filename>, for network and SCSI interface drivers respectively.</para>
+ <para>By default, <command>modprobe</command> attempts to load the module from <filename class="directory">/lib/modules/<replaceable>kernel_version</replaceable>/kernel/drivers/</filename>. In this directory, each type of module has its own subdirectory, such as <filename class="directory">net/</filename> and <filename class="directory">scsi/</filename>, for network and SCSI interface drivers respectively.</para>
<para>Some modules have dependencies, which are other kernel modules that must be loaded before the module in question can be loaded. The <command>modprobe</command> command always takes dependencies into account when performing operations. When you ask <command>modprobe</command> to load a specific kernel module, it first examines the dependencies of that module, if there are any, and loads them if they are not already loaded into the kernel. <command>modprobe</command> resolves dependencies recursively: it will load all dependencies of dependencies, and so on, if necessary, thus ensuring that all dependencies are always met.<!-- Because of this, there is no need to determine and resolve module dependencies manually.-->
</para>
- <para>You can use the <option>-v</option> (or <option>--verbose</option>) option to cause <command>modprobe</command> to display detailed information about what it is doing, which may include loading module dependencies.</para>
+ <para>You can use the <option>-v</option> (or <option>--verbose</option>) option to cause <command>modprobe</command> to display detailed information about what it is doing, which can include loading module dependencies.</para>
<example
id="ex-modprobe_-v_shows_module_dependencies_as_they_are_loaded">
<title>modprobe -v shows module dependencies as they are loaded</title>
@@ -304,14 +290,10 @@ insmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/fcoe/fcoe.ko</scree
<indexterm>
<primary>kernel module</primary>
<secondary>utilities</secondary>
- <tertiary>
- <command>insmod</command>
- </tertiary>
+ <tertiary><command>insmod</command></tertiary>
</indexterm>
<indexterm>
- <primary>
- <command>insmod</command>
- </primary>
+ <primary><command>insmod</command></primary>
<seealso>kernel module</seealso>
</indexterm>
<important
@@ -330,14 +312,10 @@ insmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/fcoe/fcoe.ko</scree
<indexterm>
<primary>kernel module</primary>
<secondary>utilities</secondary>
- <tertiary>
- <command>modprobe</command>
- </tertiary>
+ <tertiary><command>modprobe</command></tertiary>
</indexterm>
<indexterm>
- <primary>
- <command>modprobe</command>
- </primary>
+ <primary><command>modprobe</command></primary>
<seealso>kernel module</seealso>
</indexterm>
<para>You can unload a kernel module by running <command>modprobe -r <replaceable>module_name</replaceable> </command> as <systemitem class="username">root</systemitem>. For example, assuming that the <systemitem class="resource">wacom</systemitem> module is already loaded into the kernel, you can unload it by running:</para>
@@ -347,15 +325,15 @@ insmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/fcoe/fcoe.ko</scree
<itemizedlist>
<listitem>
<para>the <systemitem
- class="resource">wacom</systemitem> module,</para>
+ class="resource">wacom</systemitem> module;</para>
</listitem>
<listitem>
<para>a module that <systemitem
- class="resource">wacom</systemitem> directly depends on, or,</para>
+ class="resource">wacom</systemitem> directly depends on, or;</para>
</listitem>
<listitem>
<para>any module that <systemitem
- class="resource">wacom</systemitem>—through the dependency tree—depends on indirectly.</para>
+ class="resource">wacom</systemitem>, through the dependency tree, depends on indirectly.</para>
</listitem>
</itemizedlist>
<para>Refer to <xref linkend="sec-Listing_Currently-Loaded_Modules"/> for more information about using <command>lsmod</command> to obtain the names of the modules which are preventing you from unloading a certain module.</para>
@@ -379,14 +357,10 @@ rmmod /lib/modules/2.6.32-71.el6.x86_64/kernel/lib/crc-itu-t.ko</screen>
<indexterm>
<primary>kernel module</primary>
<secondary>utilities</secondary>
- <tertiary>
- <command>rmmod</command>
- </tertiary>
+ <tertiary><command>rmmod</command></tertiary>
</indexterm>
<indexterm>
- <primary>
- <command>rmmod</command>
- </primary>
+ <primary><command>rmmod</command></primary>
<seealso>kernel module</seealso>
</indexterm>
<important
@@ -477,10 +451,7 @@ rmmod /lib/modules/2.6.32-71.el6.x86_64/kernel/lib/crc-itu-t.ko</screen>
<indexterm>
<primary>kernel module</primary>
<secondary>directories</secondary>
- <tertiary>
- <filename
- class="directory">/etc/sysconfig/modules/</filename>
- </tertiary>
+ <tertiary><filename class="directory">/etc/sysconfig/modules/</filename></tertiary>
</indexterm>
<para>As shown in <xref
linkend="ex-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 creating a new <filename><replaceable>file_name</replaceable>.modules</filename> file in the <filename class="directory">/etc/sysconfig/modules/</filename> directory, where <replaceable>file_name</replaceable> is any descriptive name of your choice. Your <filename><replaceable>file_name</replaceable>.modules</filename> files are treated by the system startup scripts as shell scripts, and as such should begin with an <firstterm>interpreter directive</firstterm> (also called a <quote>bang line</quote>) as their first line:</para>
@@ -518,7 +489,7 @@ fi</programlisting>
<para>For more information on kernel modules and their utilities, refer to the following resources.</para>
<section id="s2-kernel-modules-additional-resources-installed">
<title>Installed Documentation</title>
- <para>There is a number of manual pages for various utilities related to the kernel modules:</para>
+ <para>There are a number of manual pages for various utilities related to kernel modules:</para>
<variablelist>
<varlistentry>
<term><command>man lsmod</command></term>
9 years, 8 months