[system-administrators-guide] Update after translators and SME review
by stephenw
commit 5a636949a93542dee1860f682110006c9b925ab7
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Nov 24 20:28:37 2014 +0100
Update after translators and SME review
en-US/Configuring_NTP_Using_the_chrony_Suite.xml | 99 +++++++++++-----------
1 files changed, 50 insertions(+), 49 deletions(-)
---
diff --git a/en-US/Configuring_NTP_Using_the_chrony_Suite.xml b/en-US/Configuring_NTP_Using_the_chrony_Suite.xml
index efaff6d..8a23bad 100644
--- a/en-US/Configuring_NTP_Using_the_chrony_Suite.xml
+++ b/en-US/Configuring_NTP_Using_the_chrony_Suite.xml
@@ -199,7 +199,7 @@ Optionally specify a host, subnet, or network from which to allow <systemitem cl
<term>local</term>
<listitem>
<para>
- The <command>local</command> keyword is used to allow <systemitem class="daemon">chronyd</systemitem> to appear synchronized to real time (from the viewpoint of clients polling it), even if it has no current synchronization source. This option is normally used on computers in an isolated network, where several computers are required to synchronize to one other, this being the <quote>master</quote> which is kept vaguely in line with real time by manual input.</para>
+ The <command>local</command> keyword is used to allow <systemitem class="daemon">chronyd</systemitem> to appear synchronized to real time from the viewpoint of clients polling it, even if it has no current synchronization source. This option is normally used on the <quote>master</quote> computer in an isolated network, where several computers are required to synchronize to one another, and the <quote>master</quote> is kept in line with real time by manual input.</para>
<para>
An example of the command is:
<screen>local stratum 10</screen>
@@ -417,7 +417,7 @@ peer w.x.y.z key 10
<para>
A manual entry in the key file, used to authenticate packets from certain <systemitem class="protocol">NTP</systemitem> servers or peers, can be as simple as the following:
<screen>20 foobar</screen>
- 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.
+ Where <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 <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.
@@ -482,20 +482,13 @@ chronyc> <command>password HEX:A6CFC50C9C93AB6E5A19754C246242FC5471BCDF</command
<title>Using chrony</title>
-<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 <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>
- </section>
+
<section id="sect-Installing_chrony">
<title>Installing chrony</title>
<para>
-To install <application>chrony</application>, run the following command as <systemitem class="username">root</systemitem>:
- <screen>~]# <command>yum install chrony -y</command></screen>
+ The <application>chrony</application> suite is installed by default on some versions of Fedora. If required, to ensure that it is, 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>
</section>
@@ -505,7 +498,7 @@ The default location for the <application>chrony</application> daemon is <filena
<title>Checking the Status of chronyd</title>
<para>
To check the status of <systemitem class="daemon">chronyd</systemitem>, issue the following command:
- <screen>~]$ <command>systemctl status chronyd</command>
+ <screen>~]$ <command>systemctl status chronyd</command>
chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled)
Active: active (running) since Wed 2013-06-12 22:23:16 CEST; 11h ago</screen>
@@ -515,22 +508,22 @@ chronyd.service - NTP client/server
<title>Starting chronyd</title>
<para>
To start <systemitem class="daemon">chronyd</systemitem>, issue the following command as <systemitem class="username">root</systemitem>:
- <screen>~]# <command>systemctl start chronyd</command></screen>
+ <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 <systemitem class="username">root</systemitem>:
- <screen>~]# <command>systemctl enable chronyd</command></screen>
+ <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 <systemitem class="username">root</systemitem>:
- <screen>~]# <command>systemctl stop chronyd</command></screen>
+ <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 <systemitem class="username">root</systemitem>:
- <screen>~]# <command>systemctl disable chronyd</command></screen>
+ <screen>~]# <command>systemctl disable chronyd</command></screen>
</para>
</section>
@@ -546,7 +539,7 @@ chronyd.service - NTP client/server
<para>
To check <application>chrony</application> tracking, issue the following command:
- <screen>~]$ <command>chronyc tracking</command>
+ <screen>~]$ <command>chronyc tracking</command>
Reference ID : 1.2.3.4 (a.b.c)
Stratum : 3
Ref time (UTC) : Fri Feb 3 15:00:29 2012
@@ -561,7 +554,7 @@ Root dispersion : 0.024780 seconds
Update interval : 64.2 seconds
Leap status : Normal
</screen>
- The fields are as follows:
+ The fields are as follows:
</para>
<variablelist>
<varlistentry>
@@ -612,7 +605,7 @@ Leap status : Normal
<term>Frequency</term>
<listitem>
<para>
- The <quote>frequency</quote> is the rate by which the system’s clock would be would be wrong if <systemitem class="daemon">chronyd</systemitem> was not correcting it. It is expressed in ppm (parts per million). For example, a value of 1ppm would mean that when the system’s clock thinks it has advanced 1 second, it has actually advanced by 1.000001 seconds relative to true time.</para>
+ The <quote>frequency</quote> is the rate by which the system’s clock would be wrong if <systemitem class="daemon">chronyd</systemitem> was not correcting it. It is expressed in ppm (parts per million). For example, a value of 1ppm would mean that when the system’s clock thinks it has advanced 1 second, it has actually advanced by 1.000001 seconds relative to true time.</para>
</listitem>
</varlistentry>
<varlistentry>
@@ -666,16 +659,14 @@ This is the total dispersion accumulated through all the computers back to the s
The sources command displays information about the current time sources that <systemitem class="daemon">chronyd</systemitem> is accessing.
The optional argument -v can be specified, meaning verbose. In this case, extra caption lines are shown as a reminder of the meanings of the columns.
- <screen>~]$ <command>chronyc sources</command>
+ <screen>~]$ <command>chronyc sources</command>
210 Number of sources = 3
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#* GPS0 0 4 377 11 -479ns[ -621ns] +/- 134ns
^? a.b.c 2 6 377 23 -923us[ -924us] +/- 43ms
-^+ d.e.f 1 6 377 21 -2629us[-2619us] +/- 86ms
-
-</screen>
-The columns are as follows:
+^+ d.e.f 1 6 377 21 -2629us[-2619us] +/- 86ms</screen>
+The columns are as follows:
<variablelist>
<varlistentry>
<term>M</term>
@@ -689,7 +680,7 @@ This indicates the mode of the source. <literal>^</literal> means a server, <lit
<term>S</term>
<listitem>
<para>
-This column indicates the state of the sources. <quote>*</quote> indicates the source to which <systemitem class="daemon">chronyd</systemitem> is currently synchronized. <quote>+</quote> indicates acceptable sources which are combined with the selected source. <quote>-</quote> indicates acceptable sources which are excluded by the combining algorithm. <quote>?</quote> indicates sources to which connectivity has been lost or whose packets do not pass all tests. <quote>x</quote> indicates a clock which <systemitem class="daemon">chronyd</systemitem> thinks is a <firstterm>falseticker</firstterm> ( its time is inconsistent with a majority of other sources). <quote>~</quote> indicates a source whose time appears to have too much
+This column indicates the state of the sources. <quote>*</quote> indicates the source to which <systemitem class="daemon">chronyd</systemitem> is currently synchronized. <quote>+</quote> indicates acceptable sources which are combined with the selected source. <quote>-</quote> indicates acceptable sources which are excluded by the combining algorithm. <quote>?</quote> indicates sources to which connectivity has been lost or whose packets do not pass all tests. <quote>x</quote> indicates a clock which <systemitem class="daemon">chronyd</systemitem> thinks is a <firstterm>falseticker</firstterm> (its time is inconsistent with a majority of other sources). <quote>~</quote> indicates a source whose time appears to have too much
variability. The <quote>?</quote> condition is also shown at start-up, until at least 3 samples have been gathered from it.</para>
</listitem>
</varlistentry>
@@ -739,7 +730,7 @@ This shows the stratum of the source, as reported in its most recently received
<term>Last sample</term>
<listitem>
<para>
- 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 <literal>ns</literal> (indicating nanoseconds), <literal>us</literal> (indicating microseconds), <literal>ms</literal> (indicating milliseconds), or <literal>s</literal> (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 <literal>+/-</literal> indicator shows the margin of error in the measurement. Positive offsets indicate that the local clock is fast of the source.
+ 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 <literal>ns</literal> (indicating nanoseconds), <literal>us</literal> (indicating microseconds), <literal>ms</literal> (indicating milliseconds), or <literal>s</literal> (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 <literal>+/-</literal> indicator shows the margin of error in the measurement. Positive offsets indicate that the local clock is ahead of the source.
</para>
</listitem>
</varlistentry>
@@ -754,16 +745,13 @@ This shows the stratum of the source, as reported in its most recently received
The <command>sourcestats</command> command displays information about the drift rate and offset estimation process for each of the sources currently being examined by <systemitem class="daemon">chronyd</systemitem>.
The optional argument <option>-v</option> can be specified, meaning verbose. In this case, extra caption lines are shown as a reminder of the meanings of the columns.
- <screen>~]$ <command>chronyc sourcestats</command>
-
-
+ <screen>~]$ <command>chronyc sourcestats</command>
210 Number of sources = 1
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
===============================================================================
-abc.def.ghi
-</screen>
+abc.def.ghi 11 5 46m -0.001 0.045 1us 25us</screen>
-The columns are as follows:
+The columns are as follows:
<variablelist>
<varlistentry>
@@ -839,7 +827,7 @@ This is the estimated error bounds on Freq (again in parts per million).
<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 <systemitem class="username">root</systemitem>:
- <screen>~]# <command>chronyc</command>
+ <screen>~]# <command>chronyc</command>
chrony> <command>password</command> <replaceable>commandkey-password</replaceable>
200 OK
chrony> <command>makestep</command>
@@ -847,7 +835,7 @@ This is the estimated error bounds on Freq (again in parts per million).
Where <replaceable>commandkey-password</replaceable> is the command key or password stored in the key file.
</para>
<para>
- The real-time clock should not be manually adjusted if the <command>rtcfile</command> directive is used as this would interfere with <application>chrony</application>'s need to measure the rate at which the real-time clock drifts if it was adjusted at random intervals.
+If the <command>rtcfile</command> directive is used, the real-time clock should not be manually adjusted. Random adjustments would interfere with <application>chrony</application>'s need to measure the rate at which the real-time clock drifts.
</para>
<para>
If <application>chronyc</application> is used to configure the local <application>chronyd</application>, the <option>-a</option> will run the <command>authhash</command> and <command>password</command> commands automatically. This means that the interactive session illustrated above can be replaced by:
@@ -926,9 +914,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 <systemitem class="username">root</systemitem>:
- <screen>~]# <command>chronyc</command></screen>
- <application>chronyc</application> must run as <systemitem class="username">root</systemitem> if some of the restricted commands are to be used.
+ To make changes to the local instance of <systemitem class="daemon">chronyd</systemitem> using the command line utility <application>chronyc</application> in interactive mode, enter the following command as <systemitem class="username">root</systemitem>:
+ <screen>~]# <command>chronyc -a</command></screen>
+ <application>chronyc</application> must run as <systemitem class="username">root</systemitem> if some of the restricted commands are to be used. The <option>-a</option> option is for automatic authentication using the local keys when configuring <systemitem class="daemon">chronyd</systemitem> on the local system. See <xref linkend="sect-Security_with_chronyc" /> for more information.
</para>
<para>
The <application>chronyc</application> command prompt will be displayed as follows:</para>
@@ -936,32 +924,45 @@ Where <systemitem class="ipaddress">192.0.2.123</systemitem> is the address of t
<para>
You can type <command>help</command> to list all of the commands.
</para>
-
+
<para>
The utility can also be invoked in non-interactive command mode if called together with a command as follows:
- <screen>~]# <command>chronyc <replaceable>command</replaceable></command></screen>
+ <synopsis><command>chronyc <replaceable>command</replaceable></command></synopsis>
</para>
+ <note>
+ <para>
+ Changes made using <application>chronyc</application> are not permanent, they will be lost after a <systemitem class="daemon">chronyd</systemitem> restart. For permanent changes, modify <filename>/etc/chrony.conf</filename>.
+ </para>
+ </note>
</section>
<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 <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.
+To configure <application>chrony</application> to connect to a remote instance of <systemitem class="daemon">chronyd</systemitem>, issue a command in the following format:
+<screen>~]$ <command>chronyc <option>-h</option> <replaceable>hostname</replaceable></command></screen>
+Where <replaceable>hostname</replaceable> is the host name to connect to. The default is to connect to the local daemon.
</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 <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.
+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 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 remote instance of <systemitem class="daemon">chronyd</systemitem>.
</para>
<para>
-Note that commands issued at the <application>chrony</application> command prompt are not persistent. Only commands in the configuration file are persistent.
+Note that commands issued at the <application>chronyc</application> command prompt are not persistent. Only commands in the configuration file are persistent.
</para>
+ <para>
+The first command must be the <command>password</command> command at the <application>chronyc</application> command prompt as follows:
+ <screen>chronyc> <command>password <replaceable>password</replaceable></command>
+200 OK</screen>
+The password should not have any spaces.
+ </para>
+
<para>
-From the remote systems, the system administrator can issue commands after first using the <command>password</command> command, preceded by the <command>authhash</command> command if the key used a hash different from MD5, at the <application>chronyc</application> command prompt as follows:
- <screen>chronyc> <command>password secretpasswordwithnospaces</command>
+ If the password is not an MD5 hash, the hashed password must be preceded by the <command>authhash</command> command as follows:
+ <screen>chronyc> <command>authhash SHA1</command>
+chronyc> <command>password HEX:A6CFC50C9C93AB6E5A19754C246242FC5471BCDF</command>
200 OK</screen>
</para>
9 years, 5 months
[system-administrators-guide] Markup and layout improvements
by stephenw
commit 3165ee7bb67c6e5942fdfc481cd7acc7c8a11972
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Nov 24 20:10:13 2014 +0100
Markup and layout improvements
en-US/Configuring_PTP_Using_ptp4l.xml | 59 +++++++++++++++++++-------------
1 files changed, 35 insertions(+), 24 deletions(-)
---
diff --git a/en-US/Configuring_PTP_Using_ptp4l.xml b/en-US/Configuring_PTP_Using_ptp4l.xml
index ad6a2b6..ea6aab9 100644
--- a/en-US/Configuring_PTP_Using_ptp4l.xml
+++ b/en-US/Configuring_PTP_Using_ptp4l.xml
@@ -55,7 +55,7 @@
<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:
- <screen>~]# <command>ethtool -T <replaceable>em3</replaceable></command>
+ <screen>~]# <command>ethtool -T <replaceable>em3</replaceable></command>
Time stamping parameters for em3:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
@@ -71,7 +71,7 @@ Hardware Transmit Timestamp Modes:
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)</screen>
- Where <replaceable>em3</replaceable> is the interface you wish to check.
+ Where <replaceable>eth3</replaceable> is the interface you want to check.
</para>
<para>
For software time stamping support, the parameters list
@@ -135,7 +135,7 @@ should include:
<title>Installing PTP</title>
<para>
The kernel in Fedora 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>:
- <screen>~]# <command>yum install linuxptp</command></screen>
+ <screen>~]# <command>yum install linuxptp</command></screen>
This will install <application>ptp4l</application> and <application>phc2sys</application>.
</para>
<para>
@@ -147,9 +147,9 @@ should include:
<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>:
-<screen>~]# <command>ptp4l -i <replaceable>em3</replaceable> -m</command></screen>
-Where <replaceable>em3</replaceable> is the interface you wish to configure. Below is example output from <application>ptp4l</application> when the <systemitem class="protocol">PTP</systemitem> clock on the NIC is synchronized to a master:
-<screen>~]# <command>ptp4l -i <replaceable>em3</replaceable> -m</command>
+<screen>~]# <command>ptp4l -i <replaceable>em3</replaceable> -m</command></screen>
+Where <replaceable>em3</replaceable> is the interface you want to configure. Below is example output from <application>ptp4l</application> when the <systemitem class="protocol">PTP</systemitem> clock on the NIC is synchronized to a master:
+<screen>~]# <command>ptp4l -i <replaceable>em3</replaceable> -m</command>
selected em3 as PTP clock
port 1: INITIALIZING to LISTENING on INITIALIZE
port 0: INITIALIZING to LISTENING on INITIALIZE
@@ -168,7 +168,7 @@ The master offset value is the measured offset from the master in nanoseconds. T
</para>
<para>
The <application>ptp4l</application> program can also be started as a service by running:
-<screen>~]# <command>systemctl start ptp4l</command></screen>
+<screen>~]# <command>systemctl start ptp4l</command></screen>
When running as a service, options are specified in the <filename>/etc/sysconfig/ptp4l</filename> file. More information on the different <application>ptp4l</application> options and the configuration file settings can be found in the <filename>ptp4l(8)</filename> man page.
</para>
<para>
@@ -176,7 +176,7 @@ By default, messages are sent to <filename>/var/log/messages</filename>. However
</para>
<para>
To enable software time stamping, the <option>-S</option> option needs to be used as follows:
- <screen>~]# <command>ptp4l -i <replaceable>em3</replaceable> -m -S</command></screen>
+ <screen>~]# <command>ptp4l -i <replaceable>em3</replaceable> -m -S</command></screen>
</para>
<section id="sec-Selecting_a_Delay_Mechanism">
@@ -220,8 +220,19 @@ By default, messages are sent to <filename>/var/log/messages</filename>. However
</variablelist>
<note>
<para>
- All clocks on a single <systemitem class="protocol">PTP</systemitem> communication path must use the same mechanism to measure the delay. A warning will be printed when a peer delay request is received on a port using the <acronym>E2E</acronym> mechanism. A warning will be printed when a <acronym>E2E</acronym> delay request is received on a port using the <acronym>P2P</acronym> mechanism.
- </para>
+ All clocks on a single <systemitem class="protocol">PTP</systemitem> communication path must use the same mechanism to measure the delay. Warnings will be printed in the following circumstances:</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ When a peer delay request is received on a port using the <acronym>E2E</acronym> mechanism.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ When a <acronym>E2E</acronym> delay request is received on a port using the <acronym>P2P</acronym> mechanism.
+ </para>
+ </listitem>
+ </itemizedlist>
</note>
</para>
</section>
@@ -236,11 +247,11 @@ By default, messages are sent to <filename>/var/log/messages</filename>. However
</para>
<para>
No configuration file is read by default, so it needs to be specified at runtime with the <option>-f</option> option. For example:
- <screen>~]# <command>ptp4l -f /etc/ptp4l.conf</command></screen>
+ <screen>~]# <command>ptp4l -f /etc/ptp4l.conf</command></screen>
</para>
<para>
A configuration file equivalent to the <command>-i em3 -m -S</command> options shown above would look as follows:
-<screen>~]# <command>cat /etc/ptp4l.conf</command>
+<screen>~]# <command>cat /etc/ptp4l.conf</command>
[global]
verbose 1
time_stamping software
@@ -255,7 +266,7 @@ time_stamping software
The <systemitem class="protocol">PTP</systemitem> management client, <application>pmc</application>, can be used to obtain additional information from <application>ptp4l</application> as follows:
</para>
<para>
- <screen>~]# <command>pmc -u -b 0 'GET CURRENT_DATA_SET'</command>
+ <screen>~]# <command>pmc -u -b 0 'GET CURRENT_DATA_SET'</command>
sending: GET CURRENT_DATA_SET
90e2ba.fffe.20c7f8-0 seq 0 RESPONSE MANAGMENT CURRENT_DATA_SET
stepsRemoved 1
@@ -263,7 +274,7 @@ sending: GET CURRENT_DATA_SET
meanPathDelay 9310.0</screen>
</para>
<para>
- <screen>~]# <command>pmc -u -b 0 'GET TIME_STATUS_NP'</command>
+ <screen>~]# <command>pmc -u -b 0 'GET TIME_STATUS_NP'</command>
sending: GET TIME_STATUS_NP
90e2ba.fffe.20c7f8-0 seq 0 RESPONSE MANAGMENT TIME_STATUS_NP
master_offset 310
@@ -307,7 +318,7 @@ if <literal>gmPresent</literal> is true, the <systemitem class="protocol">PTP</s
</para>
<para>
For a full list of <application>pmc</application> commands, type the following as <systemitem class="username">root</systemitem>:
- <screen>~]# <command>pmc help</command></screen>
+ <screen>~]# <command>pmc help</command></screen>
Additional information is available in the <filename>pmc(8)</filename> man page.
</para>
</section>
@@ -316,18 +327,18 @@ if <literal>gmPresent</literal> is true, the <systemitem class="protocol">PTP</s
<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>:
- <screen>~]# <command>phc2sys -s <replaceable>em3</replaceable> -w</command></screen>
+ <screen>~]# <command>phc2sys -s <replaceable>em3</replaceable> -w</command></screen>
The <option>-w</option> option waits for the running <application>ptp4l</application> application to synchronize the <systemitem class="protocol">PTP</systemitem> clock and then retrieves the <acronym>TAI</acronym> to <acronym>UTC</acronym> offset from <application>ptp4l</application>.
</para>
<para>
Normally, <systemitem class="protocol">PTP</systemitem> operates in the <firstterm>International Atomic Time</firstterm> (<acronym>TAI</acronym>) timescale, while the system clock is kept in <firstterm>Coordinated Universal Time</firstterm> (<acronym>UTC</acronym>). The current offset between the TAI and UTC timescales is 35 seconds. The offset changes when leap seconds are inserted or deleted, which typically happens every few years. The <option>-O</option> option needs to be used to set this offset manually when the <option>-w</option> is not used, as follows:
-<screen>~]# <command>phc2sys -s <replaceable>em3</replaceable> -O -35</command></screen>
+<screen>~]# <command>phc2sys -s <replaceable>em3</replaceable> -O -35</command></screen>
</para>
<para>
Once the <application>phc2sys</application> servo is in a locked state, the clock will not be stepped, unless the <option>-S</option> option is used. This means that the <application>phc2sys</application> program should be started after the <application>ptp4l</application> program has synchronized the <systemitem class="protocol">PTP</systemitem> hardware clock. However, with <option>-w</option>, it is not necessary to start <application>phc2sys</application> after <application>ptp4l</application> as it will wait for it to synchronize the clock.</para>
<para>
The <application>phc2sys</application> program can also be started as a service by running:
-<screen>~]# <command>systemctl start phc2sys</command></screen>
+<screen>~]# <command>systemctl start phc2sys</command></screen>
When running as a service, options are specified in the <filename>/etc/sysconfig/phc2sys</filename> file. More information on the different <application>phc2sys</application> options can be found in the <filename>phc2sys(8)</filename> man page.
</para>
<para>
@@ -411,10 +422,10 @@ ptp4l: [1133.125] rms 226 max 505 freq -29792 ± 197 delay 9225 ± 159
ptp4l: [1197.185] rms 244 max 688 freq -29790 ± 211 delay 9201 ± 162
</screen>
To reduce the output from the <application>phc2sys</application>, it can be called it with the <option>-u</option> option as follows:
- <screen>~]# <command>phc2sys -u <replaceable>summary-updates</replaceable></command></screen>
+ <screen>~]# <command>phc2sys -u <replaceable>summary-updates</replaceable></command></screen>
Where <replaceable>summary-updates</replaceable> is the number of clock updates to include in summary statistics. An example follows:
<screen>
-~]# <command>phc2sys -s em3 -w -m -u 60</command>
+~]# <command>phc2sys -s em3 -w -m -u 60</command>
phc2sys[700.948]: rms 1837 max 10123 freq -36474 ± 4752 delay 2752 ± 16
phc2sys[760.954]: rms 194 max 457 freq -37084 ± 174 delay 2753 ± 12
phc2sys[820.963]: rms 211 max 487 freq -37085 ± 185 delay 2750 ± 19
@@ -431,7 +442,7 @@ phc2sys[1060.984]: rms 266 max 675 freq -36759 ± 234 delay 2753 ± 17
<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>:
<screen>
-~]# <command>cat /etc/ntp.conf</command>
+~]# <command>cat /etc/ntp.conf</command>
server 127.127.1.0
fudge 127.127.1.0 stratum 0</screen>
</para>
@@ -446,7 +457,7 @@ fudge 127.127.1.0 stratum 0</screen>
<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>:
-<screen>~]# <command>cat /etc/ptp4l.conf</command>
+<screen>~]# <command>cat /etc/ptp4l.conf</command>
[global]
priority1 127
[em3]
@@ -454,11 +465,11 @@ priority1 127
</para>
<para>
With hardware time stamping, <application>phc2sys</application> needs to be used to synchronize the <systemitem class="protocol">PTP</systemitem> hardware clock to the system clock:
-<screen>~]# <command>phc2sys -c <replaceable>em3</replaceable> -s CLOCK_REALTIME -w</command></screen>
+<screen>~]# <command>phc2sys -c <replaceable>em3</replaceable> -s CLOCK_REALTIME -w</command></screen>
</para>
<para>
To prevent quick changes in the <systemitem class="protocol">PTP</systemitem> clock's frequency, the synchronization to the system clock can be loosened by using smaller <option>P</option> (proportional) and <option>I</option> (integral) constants of the PI servo:
-<screen>~]# <command>phc2sys -c <replaceable>em3</replaceable> -s CLOCK_REALTIME -w -P 0.01 -I 0.0001</command></screen>
+<screen>~]# <command>phc2sys -c <replaceable>em3</replaceable> -s CLOCK_REALTIME -w -P 0.01 -I 0.0001</command></screen>
</para>
</section>
9 years, 5 months
[system-administrators-guide] Update after translators and SME review
by stephenw
commit e6c358613c18646a2ff1ce1ea4164a3c76dbcb1b
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Nov 24 18:08:47 2014 +0100
Update after translators and SME review
en-US/Configuring_NTP_Using_ntpd.xml | 125 +++++++++++++++++++++++-----------
1 files changed, 84 insertions(+), 41 deletions(-)
---
diff --git a/en-US/Configuring_NTP_Using_ntpd.xml b/en-US/Configuring_NTP_Using_ntpd.xml
index c956c70..be44744 100644
--- a/en-US/Configuring_NTP_Using_ntpd.xml
+++ b/en-US/Configuring_NTP_Using_ntpd.xml
@@ -14,7 +14,7 @@
The <firstterm>Network Time Protocol</firstterm> (<acronym>NTP</acronym>) 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 u
sed. These <systemitem class="protocol">NTP</systemitem> servers provide <quote><firstterm>Coordinated Universal Time</firstterm></quote> (<acronym>UTC</acronym>). Information about these time servers can found at <citetitle pubwork="webpage">www.pool.ntp.org</citetitle>.
</para>
<para>
- 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. Logs are used to investigate service and security issues and so timestamps made on different systems must be made by synchronized clocks to be of real value. As systems and networks become increasingly faster, there is a corresponding need for clocks with greater accuracy and resolution. In some countries there are legal obligations to keep accurately synchronized clocks. Please see <citetitle pubwork="webpage">www.ntp.org</citetitle> for more information. In Linux systems, <systemitem class="protocol">NTP</systemitem> is implemented by a daemon running in user space. The default <systemitem class="protocol">NTP</systemitem> user space daemon in &MAJOROSVER; is <systemitem class="service">chronyd</systemitem>. It must be disabled if you want to use the <systemitem class="service">ntpd</systemitem> daemon. See <xref linkend=
"ch-Configuring_NTP_Using_the_chrony_Suite" /> for information on <application>chrony</application>.
+ 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. Logs are used to investigate service and security issues and so time stamps made on different systems must be made by synchronized clocks to be of real value. As systems and networks become increasingly faster, there is a corresponding need for clocks with greater accuracy and resolution. In some countries there are legal obligations to keep accurately synchronized clocks. Please see <citetitle pubwork="webpage">www.ntp.org</citetitle> for more information. In Linux systems, <systemitem class="protocol">NTP</systemitem> is implemented by a daemon running in user space. The default <systemitem class="protocol">NTP</systemitem> user space daemon in &MAJOROSVER; is <systemitem class="service">chronyd</systemitem>. It must be disabled if you want to use the <systemitem class="service">ntpd</systemitem> daemon. See <xref linkend
="ch-Configuring_NTP_Using_the_chrony_Suite" /> for information on <application>chrony</application>.
</para>
<para>
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 <quote><firstterm>Real Time Clock</firstterm></quote> <acronym>(RTC)</acronym>. See the <filename>rtc(4)</filename> and <filename>hwclock(8)</filename> man pages for information on hardware clocks. The system clock can keep time by using various clock sources. Usually, the <firstterm>Time Stamp Counter</firstterm> (<acronym>TSC</acronym>) 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 synchroni
zed with external time references. When the system clock is being synchronized by <systemitem class="service">ntpd</systemitem>, the kernel will in turn update the RTC every 11 minutes automatically.
@@ -125,15 +125,15 @@
Specification, Implementation and Analysis</citetitle></ulink> and <ulink url="http://www.rfc-editor.org/info/rfc5905"><citetitle pubwork="webpage">RFC 5905 Network Time Protocol Version 4: Protocol and Algorithms Specification</citetitle></ulink>
</para>
<para>
- This implementation of <systemitem class="protocol">NTP</systemitem> enables sub-second accuracy to be achieved. Over the Internet, accuracy to 10s of milliseconds is normal. On a Local Area Network (LAN), 1 ms accuracy is possible under ideal conditions. This is because clock drift is now accounted and corrected for, which was not done in earlier, simpler, time protocol systems. A resolution of 233 picoseconds is provided by using 64-bit timestamps: 32-bits for seconds, 32-bits for fractional seconds.
+ This implementation of <systemitem class="protocol">NTP</systemitem> enables sub-second accuracy to be achieved. Over the Internet, accuracy to 10s of milliseconds is normal. On a Local Area Network (LAN), 1 ms accuracy is possible under ideal conditions. This is because clock drift is now accounted and corrected for, which was not done in earlier, simpler, time protocol systems. A resolution of 233 picoseconds is provided by using 64-bit time stamps. The first 32-bits of the time stamp is used for seconds, the last 32-bits are used for fractions of seconds.
</para>
<para>
- <systemitem class="protocol">NTP</systemitem> represents the time as a count of the number of seconds since 00:00 (midnight) 1 January, 1900 GMT. As 32-bits is used to count the seconds, this means the time will <quote>roll over</quote> in 2036. However <systemitem class="protocol">NTP</systemitem> works on the difference between timestamps so this does not present the same level of problem as other implementations of time protocols have done. If a hardware clock accurate to better than 68 years is available at boot time then <systemitem class="protocol">NTP</systemitem> will correctly interpret the current date. The <systemitem class="protocol">NTP4</systemitem> specification provides for an <quote>Era Number</quote> and an <quote>Era Offset</quote> which can be used to make software more robust when dealing with time lengths of more than 68 years. Note, please do not confuse this with the Unix Year 2038 problem.
+ <systemitem class="protocol">NTP</systemitem> represents the time as a count of the number of seconds since 00:00 (midnight) 1 January, 1900 GMT. As 32-bits is used to count the seconds, this means the time will <quote>roll over</quote> in 2036. However <systemitem class="protocol">NTP</systemitem> works on the difference between time stamps so this does not present the same level of problem as other implementations of time protocols have done. If a hardware clock that is within 68 years of the correct time is available at boot time then <systemitem class="protocol">NTP</systemitem> will correctly interpret the current date. The <systemitem class="protocol">NTP4</systemitem> specification provides for an <quote>Era Number</quote> and an <quote>Era Offset</quote> which can be used to make software more robust when dealing with time lengths of more than 68 years. Note, please do not confuse this with the Unix Year 2038 problem.
</para>
<para>
- The <systemitem class="protocol">NTP</systemitem> protocol provides additional information to improve accuracy. Four timestamps are used to allow the calculation of round-trip time and server response time. In order for a system in its role as <systemitem class="protocol">NTP</systemitem> client to synchronize with a reference time server, a packet is sent with an <quote>originate timestamp</quote>. When the packet arrives, the time server adds a <quote>receive timestamp</quote>. After processing the request for time and date information and just before returning the packet, it adds a <quote>transmit timestamp</quote>. When the returning packet arrives at the <systemitem class="protocol">NTP</systemitem> client, a <quote>receive timestamp</quote> is generated. The client can now calculate the total round trip time and by subtracting the processing time derive the actual traveling time. By assuming the outgoing and return trips take equal time, the single-trip delay in re
ceiving the <systemitem class="protocol">NTP</systemitem> data is calculated. The full <systemitem class="protocol">NTP</systemitem> algorithm is much more complex then presented here.</para>
+ The <systemitem class="protocol">NTP</systemitem> protocol provides additional information to improve accuracy. Four time stamps are used to allow the calculation of round-trip time and server response time. In order for a system in its role as <systemitem class="protocol">NTP</systemitem> client to synchronize with a reference time server, a packet is sent with an <quote>originate time stamp</quote>. When the packet arrives, the time server adds a <quote>receive time stamp</quote>. After processing the request for time and date information and just before returning the packet, it adds a <quote>transmit time stamp</quote>. When the returning packet arrives at the <systemitem class="protocol">NTP</systemitem> client, a <quote>receive time stamp</quote> is generated. The client can now calculate the total round trip time and by subtracting the processing time derive the actual traveling time. By assuming the outgoing and return trips take equal time, the single-trip delay
in receiving the <systemitem class="protocol">NTP</systemitem> data is calculated. The full <systemitem class="protocol">NTP</systemitem> algorithm is much more complex than presented here.</para>
<para>
- Each packet containing time information received is not immediately acted upon, but is subject to validation checks and then used together with several other samples to arrive at a reasonably good estimate of the time. This is then compared to the system clock to determine the time offset, that is to say, the difference between the system clock's time and what <systemitem class="service">ntpd</systemitem> has determined the time should be. The system clock is adjusted slowly, at most at a rate of 0.5ms per second, to reduce this offset by changing the frequency of the counter being used. It will take at least 2000 seconds to adjust the clock by 1 second using this method. This slow change is referred to as slewing and cannot go backwards. If the time offset of the clock is more than 128ms (the default setting), <systemitem class="service">ntpd</systemitem> can <quote>step</quote> the clock forwards or backwards. If the time offset at system start is greater than 1000 sec
onds then the user, or an installation script, should make a manual adjustment. See <xref linkend="ch-Configuring_the_Date_and_Time" />. With the <option>-g</option> option to the <command>ntpd</command> command (used by default), any offset at system start will be corrected, but during normal operation only offsets of up to 1000 seconds will be corrected.</para>
+ When a packet containing time information is received it is not immediately responded to, but is first subject to validation checks and then processed together with several other time samples to arrive at an estimate of the time. This is then compared to the system clock to determine the time offset, the difference between the system clock's time and what <systemitem class="service">ntpd</systemitem> has determined the time should be. The system clock is adjusted slowly, at most at a rate of 0.5ms per second, to reduce this offset by changing the frequency of the counter being used. It will take at least 2000 seconds to adjust the clock by 1 second using this method. This slow change is referred to as slewing and cannot go backwards. If the time offset of the clock is more than 128ms (the default setting), <systemitem class="service">ntpd</systemitem> can <quote>step</quote> the clock forwards or backwards. If the time offset at system start is greater than 1000 seconds
then the user, or an installation script, should make a manual adjustment. See <xref linkend="ch-Configuring_the_Date_and_Time" />. With the <option>-g</option> option to the <command>ntpd</command> command (used by default), any offset at system start will be corrected, but during normal operation only offsets of up to 1000 seconds will be corrected.</para>
<para>
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> option (unrelated to the <option>-g</option> option). Using the <option>-x</option> 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> option can be added to the <filename>/etc/sysconfig/ntpd</filename> configuration file.</para>
</section>
@@ -188,7 +188,7 @@ Virtual machines cannot access a real hardware clock and a virtual clock is not
<title>Understanding the ntpd Configuration File</title>
<para>
The daemon, <systemitem class="service">ntpd</systemitem>, reads the configuration file at system start or when the service is restarted. The default location for the file is <filename>/etc/ntp.conf</filename> and you can view the file by entering the following command:
- <screen>~]$ <command>less /etc/ntp.conf</command></screen>
+ <screen>~]$ <command>less /etc/ntp.conf</command></screen>
The configuration commands are explained briefly later in this chapter, see <xref linkend="s1-Configure_NTP" />, and more verbosely in the <filename>ntp.conf(5)</filename> man page.
</para>
<para>
@@ -211,15 +211,39 @@ Virtual machines cannot access a real hardware clock and a virtual clock is not
<listitem>
<para>
The following line sets the default access control restriction:
- <screen>restrict default kod nomodify notrap nopeer noquery</screen>
-The <option>kod</option> option means a <quote>Kiss-o'-death</quote> packet is to be sent to reduce unwanted queries.
-The <option>nomodify</option> options prevents any changes to the configuration.
-The <option>notrap</option> option prevents <systemitem class="protocol">ntpdc</systemitem> control message protocol traps.
-The <option>nopeer</option> option prevents a peer association being formed.
-The <option>noquery</option> option prevents <systemitem class="protocol">ntpq</systemitem> and <systemitem class="protocol">ntpdc</systemitem> queries, but not time queries, from being answered. The <systemitem class="protocol">ntpq</systemitem> and <systemitem class="protocol">ntpdc</systemitem> queries can be used in amplification attacks (see <ulink url="https://access.redhat.com/security/cve/CVE-2013-5211"><citetitle pubwork="webpage">CVE-2013-5211</citetitle></ulink> for more details), do not remove the <option>noquery</option> option from the <command>restrict default</command> command on publicly accessible systems.
+ <screen>restrict default nomodify notrap nopeer noquery</screen>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The <option>nomodify</option> options prevents any changes to the configuration.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The <option>notrap</option> option prevents <systemitem class="protocol">ntpdc</systemitem> control message protocol traps.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The <option>nopeer</option> option prevents a peer association being formed.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The <option>noquery</option> option prevents <systemitem class="protocol">ntpq</systemitem> and <systemitem class="protocol">ntpdc</systemitem> queries, but not time queries, from being answered.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <important>
+ <para>
+ The <systemitem class="protocol">ntpq</systemitem> and <systemitem class="protocol">ntpdc</systemitem> queries can be used in amplification attacks, therefore do not remove the <option>noquery</option> option from the <command>restrict default</command> command on publicly accessible systems.</para>
+ <para>
+ See <ulink url="https://access.redhat.com/security/cve/CVE-2013-5211"><citetitle pubwork="webpage">CVE-2013-5211</citetitle></ulink> for more details.
</para>
+ </important>
<para>
- Addresses within the range <systemitem class="ipaddress">127.0.0.0/8</systemitem> range are sometimes required by various processes or applications. As the "restrict default" line above prevents access to everything not explicitly allowed, access to the standard loopback address for <systemitem class="protocol">IPv4</systemitem> and <systemitem class="protocol">IPv6</systemitem> is permitted by means of the following lines:
+ Addresses within the range <systemitem class="ipaddress">127.0.0.0/8</systemitem> are sometimes required by various processes or applications. As the "restrict default" line above prevents access to everything not explicitly allowed, access to the standard loopback address for <systemitem class="protocol">IPv4</systemitem> and <systemitem class="protocol">IPv6</systemitem> is permitted by means of the following lines:
<screen># the administrative functions.
restrict 127.0.0.1
restrict ::1</screen>
@@ -257,7 +281,7 @@ server 3.fedora.pool.ntp.org iburst</screen>
<term>The broadcast multicast servers entry</term>
<listitem>
<para>
- By default, the <filename>ntp.conf</filename> file contains some commented out examples. These are largely self explanatory. See the explanation of the specific commands <xref linkend="s1-Configure_NTP" />. If required, add your commands just below the examples.</para>
+ By default, the <filename>ntp.conf</filename> file contains some commented out examples. These are largely self explanatory. See <xref linkend="s1-Configure_NTP" /> for the explanation of the specific commands. If required, add your commands just below the examples.</para>
</listitem>
</varlistentry>
@@ -288,11 +312,11 @@ OPTIONS="-g"</screen>
<title>Disabling chrony</title>
<para>
In order to use <systemitem class="daemon">ntpd</systemitem> the default user space daemon, <systemitem class="daemon">chronyd</systemitem>, must be stopped and disabled. Issue the following command as <systemitem class="username">root</systemitem>:
- <screen>~]# <command>systemctl stop chronyd</command></screen>
+ <screen>~]# <command>systemctl stop chronyd</command></screen>
To prevent it restarting at system start, issue the following command as <systemitem class="username">root</systemitem>:
-<screen>~]# <command>systemctl disable chronyd</command></screen>
+<screen>~]# <command>systemctl disable chronyd</command></screen>
To check the status of <systemitem class="daemon">chronyd</systemitem>, issue the following command:
-<screen>~]$ <command>systemctl status chronyd</command></screen>
+<screen>~]$ <command>systemctl status chronyd</command></screen>
</para>
</section>
@@ -301,7 +325,7 @@ To check the status of <systemitem class="daemon">chronyd</systemitem>, issue th
<title>Checking if the NTP Daemon is Installed</title>
<para>
To check if <systemitem class="service">ntpd</systemitem> is installed, enter the following command as <systemitem class="username">root</systemitem>:
- <screen>~]# <command>yum install ntp</command></screen>
+ <screen>~]# <command>yum install ntp</command></screen>
<systemitem class="protocol">NTP</systemitem> is implemented by means of the daemon or service <systemitem class="service">ntpd</systemitem>, which is contained within the <package>ntp</package> package.
</para>
</section>
@@ -310,11 +334,11 @@ To check the status of <systemitem class="daemon">chronyd</systemitem>, issue th
<title>Installing the NTP Daemon (ntpd)</title>
<para>
To install <systemitem class="service">ntpd</systemitem>, enter the following command as <systemitem class="username">root</systemitem>:
- <screen>~]# <command>yum install ntp</command></screen>
+ <screen>~]# <command>yum install ntp</command></screen>
</para>
<para>
To enable <systemitem class="service">ntpd</systemitem> at system start, enter the following command as <systemitem class="username">root</systemitem>:
- <screen>~]# <command>systemctl enable ntpd</command></screen>
+ <screen>~]# <command>systemctl enable ntpd</command></screen>
</para>
</section>
@@ -322,17 +346,17 @@ To check the status of <systemitem class="daemon">chronyd</systemitem>, issue th
<title>Checking the Status of NTP</title>
<para>
To check if <systemitem class="service">ntpd</systemitem> is running and configured to run at system start, issue the following command:
- <screen>~]$ <command>systemctl status ntpd</command></screen>
+ <screen>~]$ <command>systemctl status ntpd</command></screen>
</para>
<para>
To obtain a brief status report from <systemitem class="service">ntpd</systemitem>, issue the following command:
- <screen>~]$ <command>ntpstat</command>
+ <screen>~]$ <command>ntpstat</command>
unsynchronised
time server re-starting
polling server every 64 s</screen>
- <screen>~]$ <command>ntpstat</command>
+ <screen>~]$ <command>ntpstat</command>
synchronised to NTP server (10.5.26.10) at stratum 2
time correct to within 52 ms
polling server every 1024 s</screen>
@@ -349,11 +373,11 @@ synchronised to NTP server (10.5.26.10) at stratum 2
Check if the firewall is configured to allow incoming <systemitem class="protocol">NTP</systemitem> traffic for clients using the graphical <application>Firewall Configuration</application> tool.
</para>
<para>
- To start the graphical <application>firewall-config</application> tool, press the <keycap>Super</keycap> key to enter the Activities Overview, type <command>firewall</command> and then press <keycap>Enter</keycap>. The <application>firewall-config</application> tool appears. You will be prompted for your user password.
+ To start the graphical <application>firewall-config</application> tool, press the <keycap>Super</keycap> key to enter the Activities Overview, type <command>firewall</command> and then press <keycap>Enter</keycap>. The <guilabel>Firewall Configuration</guilabel> window opens. You will be prompted for your user password.
</para>
<para>
To start the graphical firewall configuration tool using the command line, enter the following command as <systemitem class="username">root</systemitem> user:
- <screen>~]# <command>firewall-config</command></screen>
+ <screen>~]# <command>firewall-config</command></screen>
The <guilabel>Firewall Configuration</guilabel> window opens. Note, this command can be run as normal user but you will then be prompted for the <systemitem class="username">root</systemitem> password from time to time.
</para>
<para>
@@ -364,13 +388,13 @@ synchronised to NTP server (10.5.26.10) at stratum 2
<section id="s2-Change_the_firewall_settings">
<title>Change the Firewall Settings</title>
<para>
- To immediately change the current firewall settings, ensure the current view is set to <guilabel>Runtime Configuration</guilabel>. Alternatively, to edit the settings to be applied at the next system start, or firewall reload, select <guilabel>Permanent Configuration</guilabel> from the drop-down list.
+ To immediately change the current firewall settings, ensure the drop-down selection menu labeled <guilabel>Configuration</guilabel> is set to <guimenuitem>Runtime</guimenuitem>. Alternatively, to edit the settings to be applied at the next system start, or firewall reload, select <guimenuitem>Permanent</guimenuitem> from the drop-down list.
</para>
<note>
<para>
- When making changes to the firewall settings in <guilabel>Runtime Configuration</guilabel> mode, your selection takes immediate effect when you set or clear the check box associated with the service. You should keep this in mind when working on a system that may be in use by other users.</para>
+ When making changes to the firewall settings in <guimenuitem>Runtime</guimenuitem> mode, your selection takes immediate effect when you set or clear the check box associated with the service. You should keep this in mind when working on a system that may be in use by other users.</para>
<para>
- When making changes to the firewall settings in <guilabel>Permanent Configuration</guilabel> mode, your selection will only take effect when you reload the firewall or the system restarts. You can use the reload icon below the <guilabel>File</guilabel> menu, or click the <guilabel>Options</guilabel> menu and select <guilabel>Reload Firewall</guilabel>.
+ When making changes to the firewall settings in <guimenuitem>Permanent</guimenuitem> mode, your selection will only take effect when you reload the firewall or the system restarts. To reload the firewall, select the <guimenu>Options</guimenu> menu and select <guimenuitem>Reload Firewall</guimenuitem>.
</para>
</note>
</section>
@@ -378,10 +402,10 @@ synchronised to NTP server (10.5.26.10) at stratum 2
<section id="s2-Open_Ports_in_the_firewall_for_ntp_packets">
<title>Open Ports in the Firewall for NTP Packets</title>
<para>
- To permit traffic through the firewall to a certain port, start the <application>firewall-config</application> tool and select the network zone whose settings you want to change. Select the <guilabel>Ports</guilabel> tab and the click the <guibutton>Add</guibutton> button on the right hand side. The <guilabel>Port and Protocol</guilabel> window opens.
- </para>
+ To permit traffic through the firewall to a certain port, start the <application>firewall-config</application> tool and select the network zone whose settings you want to change. Select the <guilabel>Ports</guilabel> tab and then click the <guibutton>Add</guibutton> button. The <guilabel>Port and Protocol</guilabel> window opens.
+ </para>
<para>
- Enter the port number <literal>123</literal> and select <guilabel>udp</guilabel> from the drop-down list.
+ Enter the port number <literal>123</literal> and select <guimenuitem>udp</guimenuitem> from the drop-down list.
</para>
</section>
@@ -397,11 +421,11 @@ synchronised to NTP server (10.5.26.10) at stratum 2
</para>
<para>
To check if the <systemitem class="daemon">ntpdate</systemitem> service is enabled to run at system start, issue the following command:
- <screen>~]$ <command>systemctl status ntpdate</command></screen>
+ <screen>~]$ <command>systemctl status ntpdate</command></screen>
</para>
<para>
To enable the service to run at system start, issue the following command as <systemitem class="username">root</systemitem>:
- <screen>~]# <command>systemctl enable ntpdate</command></screen>
+ <screen>~]# <command>systemctl enable ntpdate</command></screen>
</para>
<para>
@@ -563,9 +587,9 @@ synchronised to NTP server (10.5.26.10) at stratum 2
<para>
where <replaceable>address</replaceable> is an <systemitem class="protocol">IP</systemitem> broadcast or multicast address to which packets are sent.
</para>
-
+
<para>
- This command configures a system to act as an <systemitem class="protocol">NTP</systemitem> broadcast server. The address used must be a broadcast or a multicast address. Broadcast address implies the <systemitem class="protocol">IPv4</systemitem> address <systemitem class="ipaddress">255.255.255.255</systemitem>. By default, routers do not pass broadcast messages. The multicast address can be an <systemitem class="protocol">IPv4</systemitem> Class D address, or an <systemitem class="protocol">IPv6</systemitem> address. The IANA has assigned <systemitem class="protocol">IPv4</systemitem> multicast address <systemitem class="ipaddress">224.0.1.1</systemitem> and <systemitem class="protocol">IPv6</systemitem> address <systemitem class="ipaddress">FF05::101</systemitem> (site local) to <systemitem class="protocol">NTP</systemitem>. Administratively scoped<systemitem class="protocol">IPv4</systemitem> multicast addresses can also be used, as described in <ulink url="h
ttp://www.rfc-editor.org/info/rfc2365"><citetitle pubwork="webpage">RFC 2365 Administratively Scoped IP Multicast</citetitle></ulink>.
+ This command configures a system to act as an <systemitem class="protocol">NTP</systemitem> broadcast server. The address used must be a broadcast or a multicast address. Broadcast address implies the <systemitem class="protocol">IPv4</systemitem> address <systemitem class="ipaddress">255.255.255.255</systemitem>. By default, routers do not pass broadcast messages. The multicast address can be an <systemitem class="protocol">IPv4</systemitem> Class D address, or an <systemitem class="protocol">IPv6</systemitem> address. The IANA has assigned <systemitem class="protocol">IPv4</systemitem> multicast address <systemitem class="ipaddress">224.0.1.1</systemitem> and <systemitem class="protocol">IPv6</systemitem> address <systemitem class="ipaddress">FF05::101</systemitem> (site local) to <systemitem class="protocol">NTP</systemitem>. Administratively scoped <systemitem class="protocol">IPv4</systemitem> multicast addresses can also be used, as described in <ulink url="
http://www.rfc-editor.org/info/rfc2365"><citetitle pubwork="webpage">RFC 2365 Administratively Scoped IP Multicast</citetitle></ulink>.
</para>
</section>
@@ -649,7 +673,7 @@ synchronised to NTP server (10.5.26.10) at stratum 2
<synopsis><command>burst</command></synopsis>
<para>
- At every poll interval, send a burst of eight packets instead of one, when the server is responding. For use with the <command>server</command> command to improve the average quality of the time offset calculations.
+ 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> command to improve the average quality of the time-offset calculations.
</para>
</section>
@@ -661,7 +685,7 @@ synchronised to NTP server (10.5.26.10) at stratum 2
<synopsis><command>iburst</command></synopsis>
<para>
- 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> command to improve the time taken for initial synchronization. This is now a default option in the configuration file.
+ 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> command to reduce the time taken for initial synchronization. This is now a default option in the configuration file.
</para>
</section>
@@ -742,7 +766,7 @@ manycastclient 239.255.254.254 key 30</screen>
</para>
<para>
To update the hardware clock from the system clock, issue the following command as <systemitem class="username">root</systemitem>:
- <screen>~]# <command>hwclock --systohc</command></screen>
+ <screen>~]# <command>hwclock --systohc</command></screen>
</para>
<para>
When the system clock is being synchronized by <systemitem class="service">ntpd</systemitem>, the kernel will in turn update the RTC every 11 minutes automatically.
@@ -754,7 +778,7 @@ manycastclient 239.255.254.254 key 30</screen>
<title>Configuring Clock Sources</title>
<para>
To list the available clock sources on your system, issue the following commands:
- <screen>~]$ <command>cd /sys/devices/system/clocksource/clocksource0/</command>
+ <screen>~]$ <command>cd /sys/devices/system/clocksource/clocksource0/</command>
clocksource0]$ <command>cat available_clocksource</command>
kvm-clock tsc hpet acpi_pm
clocksource0]$ <command>cat current_clocksource</command>
@@ -762,9 +786,28 @@ kvm-clock</screen>
In the above example, the kernel is using <application>kvm-clock</application>. This was selected at boot time as this is a virtual machine.
</para>
<para>
- To override the default clock source, add a line similar to the following in <filename>grub.conf</filename>:
- <screen>clocksource=tsc</screen>
+ To override the default clock source, append the <command>clocksource</command> directive to the GRUB_CMDLINE_LINUX line in the <filename>/etc/default/grub</filename> file and rebuild the <filename>grub.cfg</filename> file. For example:
+ <screen>GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/root crashkernel=auto rd.lvm.lv=rhel/swap vconsole.font=latarcyrheb-sun16 vconsole.keymap=us rhgb quiet <emphasis role="bold">clocksource=tsc</emphasis>"</screen>
The available clock source is architecture dependent.</para>
+ <para>
+ Rebuild the <filename>grub.cfg</filename> file as follows:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ On BIOS-based machines, issue the following command as <systemitem class="username">root</systemitem>:
+ <screen>~]# <command>grub2-mkconfig -o /boot/grub2/grub.cfg</command></screen>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ On UEFI-based machines, issue the following command as <systemitem class="username">root</systemitem>:
+ <screen>~]# <command>grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg</command></screen>
+ </para>
+ </listitem>
+ </itemizedlist>
+ <!--See <xref linkend="sec-Configuring_the_GRUB_2_Boot_Loader" /> for more information on the <filename>grub.cfg</filename> file.-->
+ </para>
</section>
9 years, 5 months
[release-notes] No localized Anaconda help for you
by pbokoc
commit d57565c4f31b1f28adeedf1cda53834785fa200c
Author: Petr Bokoc <pbokoc(a)redhat.com>
Date: Mon Nov 24 16:08:05 2014 +0100
No localized Anaconda help for you
en-US/Installation.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/en-US/Installation.xml b/en-US/Installation.xml
index 777fe35..1da0083 100644
--- a/en-US/Installation.xml
+++ b/en-US/Installation.xml
@@ -14,7 +14,7 @@
Each screen in the installer's graphical interface and in the <application>Initial Setup</application> utility now has a <guilabel>Help</guilabel> button in the top right corner. Clicking this button opens the section of the <citetitle>Fedora Installation Guide</citetitle> relevant to the current screen using the <application>Yelp</application> help browser.
</para>
<para>
- The help is only available in the English language. Availability of other languages depends on localization progress of the <citetitle>Installation Guide</citetitle>.
+ The help is only available in the English language.
</para>
</section>
9 years, 5 months
[release-notes] Removing duplicate content from Installation
by pbokoc
commit 06e7da9423122de2c63b011b13dfbf95d402772d
Author: Petr Bokoc <pbokoc(a)redhat.com>
Date: Mon Nov 24 15:44:51 2014 +0100
Removing duplicate content from Installation
en-US/Installation.xml | 13 -------------
1 files changed, 0 insertions(+), 13 deletions(-)
---
diff --git a/en-US/Installation.xml b/en-US/Installation.xml
index f4058a8..777fe35 100644
--- a/en-US/Installation.xml
+++ b/en-US/Installation.xml
@@ -34,19 +34,6 @@
</para>
</section>
- <section id="sect-installation-help">
- <title>Built-in Help in the Graphical Interface</title>
- <para>
- The installer's graphical user interface now supports built-in help. Every screen in the installer, as well as the <application>Initial Setup</application> utility which runs the first time you reboot your system after the installation, now contains a <guilabel>Help</guilabel> button. This button opens a section of the <citetitle>Fedora Installation Guide</citetitle> relevant to the current screen in the <application>Yelp</application> help browser.
- </para>
- <para>
- At the same time, the <citetitle>Installation Guide</citetitle> is being rewritten to better match the installer's structure.
- </para>
- <para>
- Help for text mode installations is not available.
- </para>
- </section>
-
<section id="sect-installation-boot-options">
<title>Changes in Boot Options</title>
<para>
9 years, 5 months
[release-notes] Adding anaconda's shiny new built-in help to the Installer beat
by pbokoc
commit e3162e9e2dbb626141efc8759163c8fbc0b93e25
Author: Petr Bokoc <pbokoc(a)redhat.com>
Date: Mon Nov 24 15:41:43 2014 +0100
Adding anaconda's shiny new built-in help to the Installer beat
en-US/Installation.xml | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
---
diff --git a/en-US/Installation.xml b/en-US/Installation.xml
index 2a63c9a..f4058a8 100644
--- a/en-US/Installation.xml
+++ b/en-US/Installation.xml
@@ -8,6 +8,16 @@
<title>Installation</title>
<para />
+ <section id="sect-installation-anaconda-help">
+ <title>Built-in Help in the Graphical Installer</title>
+ <para>
+ Each screen in the installer's graphical interface and in the <application>Initial Setup</application> utility now has a <guilabel>Help</guilabel> button in the top right corner. Clicking this button opens the section of the <citetitle>Fedora Installation Guide</citetitle> relevant to the current screen using the <application>Yelp</application> help browser.
+ </para>
+ <para>
+ The help is only available in the English language. Availability of other languages depends on localization progress of the <citetitle>Installation Guide</citetitle>.
+ </para>
+ </section>
+
<section id="sect-installation-zram-swap">
<title>zRAM Swap Support</title>
<para>
9 years, 5 months
[system-administrators-guide] may > might (less ambiguous)
by stephenw
commit aa0244100c7a3e08f8f700b85ce9ce6ccf157e27
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Nov 24 11:18:28 2014 +0100
may > might (less ambiguous)
en-US/Manually_Upgrading_the_Kernel.xml | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
---
diff --git a/en-US/Manually_Upgrading_the_Kernel.xml b/en-US/Manually_Upgrading_the_Kernel.xml
index 07b8bca..3736442 100644
--- a/en-US/Manually_Upgrading_the_Kernel.xml
+++ b/en-US/Manually_Upgrading_the_Kernel.xml
@@ -236,7 +236,7 @@
Alternatively, on systems with a floppy drive, you can create a boot diskette by installing the <package>mkbootdisk</package> package and running the <command>mkbootdisk</command> command as <systemitem class="username">root</systemitem>. See <command>man mkbootdisk</command> man page after installing the package for usage information.
</para>
<para>
- To determine which kernel packages are installed, execute the command <command>yum list installed "kernel-*"</command> at a shell prompt. The output will comprise some or all of the following packages, depending on the system's architecture, and the version numbers may differ:
+ To determine which kernel packages are installed, execute the command <command>yum list installed "kernel-*"</command> at a shell prompt. The output will comprise some or all of the following packages, depending on the system's architecture, and the version numbers might differ:
</para>
<screen>~]# <command>yum list installed "kernel-*"</command>
Loaded plugins: langpacks, refresh-packagekit
@@ -427,13 +427,13 @@ vmlinuz-3.17.3-200.fc20.x86_64</screen>
<important id="important-initrd_files_in_the__boot_directory_are_not_the_same_as_initramfs_files">
<title>initrd files in the /boot/ directory are not the same as initramfs files</title>
<para>
- In the <filename class="directory">/boot/</filename> directory you may find several <filename>initrd-<replaceable>kernel_version</replaceable>kdump.img</filename> files. These are special files created by the <systemitem class="service">kdump</systemitem> mechanism for kernel debugging purposes, are not used to boot the system, and can safely be ignored. For more information on <systemitem class="service">kdump</systemitem>, refer to <xref linkend="ch-kdump" />.
+ In the <filename class="directory">/boot/</filename> directory you might find several <filename>initrd-<replaceable>kernel_version</replaceable>kdump.img</filename> files. These are special files created by the <systemitem class="service">kdump</systemitem> mechanism for kernel debugging purposes, are not used to boot the system, and can safely be ignored. For more information on <systemitem class="service">kdump</systemitem>, refer to <xref linkend="ch-kdump" />.
</para>
</important>
</step>
<step performance="optional">
<para>
- (Optional) If your <filename>initramfs-<replaceable>kernel_version</replaceable></filename> file does not match the version of the latest kernel in <filename>/boot</filename>, or, in certain other situations, you may need to generate an <filename>initramfs</filename> file with the <application>Dracut</application> utility. Simply invoking <command>dracut</command> as <systemitem class="username">root</systemitem> without options causes it to generate an <filename>initramfs</filename> file in the <filename class="directory">/boot/</filename> directory for the latest kernel present in that directory:
+ (Optional) If your <filename>initramfs-<replaceable>kernel_version</replaceable></filename> file does not match the version of the latest kernel in <filename>/boot</filename>, or, in certain other situations, you might need to generate an <filename>initramfs</filename> file with the <application>Dracut</application> utility. Simply invoking <command>dracut</command> as <systemitem class="username">root</systemitem> without options causes it to generate an <filename>initramfs</filename> file in the <filename class="directory">/boot/</filename> directory for the latest kernel present in that directory:
</para>
<screen>~]# <command>dracut</command></screen>
<para>
@@ -498,7 +498,7 @@ Version: dracut-037-11.git20140402.fc20
</para>
<!-- TBD6: insert link to Installation Guide -->
<para>
- It is always recommended to double-check the boot loader configuration file after installing a new kernel with <command>rpm</command> to ensure that the configuration is correct. Otherwise, the system may not be able to boot into &MAJOROS; properly. If this happens, boot the system with the boot media created earlier and re-configure the boot loader.
+ It is always recommended to double-check the boot loader configuration file after installing a new kernel with <command>rpm</command> to ensure that the configuration is correct. Otherwise, the system might not be able to boot into &MAJOROS; properly. If this happens, boot the system with the boot media created earlier and re-configure the boot loader.
</para>
<para>
In the following table, find your system's architecture to determine the boot loader it uses, and then click on the "See" link to jump to the correct instructions for your system.
9 years, 5 months
[system-administrators-guide] Change initrd to initramfs for kdump.img
by stephenw
commit 9a53f0a7d5465873aece0c879d9e86e74f5b7aa8
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Nov 24 11:15:45 2014 +0100
Change initrd to initramfs for kdump.img
Improves commit "Updates to suit Fedora 20"
en-US/Manually_Upgrading_the_Kernel.xml | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
---
diff --git a/en-US/Manually_Upgrading_the_Kernel.xml b/en-US/Manually_Upgrading_the_Kernel.xml
index 8abab0e..07b8bca 100644
--- a/en-US/Manually_Upgrading_the_Kernel.xml
+++ b/en-US/Manually_Upgrading_the_Kernel.xml
@@ -459,13 +459,13 @@ Version: dracut-037-11.git20140402.fc20
</step>
<step>
<para>
- Examine the <filename>/boot/grub2/grub.cfg</filename> configuration file to ensure that an <computeroutput>initrd <filename>/<replaceable>path</replaceable>/initramfs-<replaceable>kernel_version</replaceable>.img</filename></computeroutput> file exists for the kernel version you are booting. For example:
+ Examine the <filename>/boot/grub2/grub.cfg</filename> configuration file to ensure that an <computeroutput><filename>initramfs-<replaceable>kernel_version</replaceable>.img</filename></computeroutput> file exists for the kernel version you are booting. For example:
</para>
- <screen>~]# <command>grep initrd /boot/grub2/grub.cfg</command>
+ <screen>~]# <command>grep initramfs /boot/grub2/grub.cfg</command>
initrd /initramfs-3.17.3-200.fc20.x86_64.img
initrd /initramfs-3.17.2-200.fc20.x86_64.img
initrd /initramfs-3.16.7-200.fc20.x86_64.img
- initrd /initramfs-0-rescue-d54d78fd40ab445a9556279010454</screen>
+ initrd /initramfs-0-rescue-d54d78fd40ab445a9556279010454c22.img</screen>
<para>
See <xref linkend="s1-kernel-boot-loader" /> for more information on how to read and update the <filename>/boot/grub2/grub.cfg</filename> file.
</para>
9 years, 5 months
[system-administrators-guide] Markup, language, and style updates
by stephenw
commit d30a19a403ce28189e2899edb8026d6ce8e277b9
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Nov 24 10:10:16 2014 +0100
Markup, language, and style updates
en-US/Manually_Upgrading_the_Kernel.xml | 74 ++++++++++++-------------------
1 files changed, 28 insertions(+), 46 deletions(-)
---
diff --git a/en-US/Manually_Upgrading_the_Kernel.xml b/en-US/Manually_Upgrading_the_Kernel.xml
index 542bf7d..8abab0e 100644
--- a/en-US/Manually_Upgrading_the_Kernel.xml
+++ b/en-US/Manually_Upgrading_the_Kernel.xml
@@ -46,7 +46,7 @@
<secondary>installing kernel packages</secondary>
</indexterm>
<para>
- For more information on installing kernel packages with <application>Yum</application>, refer to <xref linkend="sec-Updating_Packages" />.
+ For more information on installing kernel packages with <application>Yum</application>, see <xref linkend="sec-Updating_Packages" />.
</para>
<section id="s1-kernel-packages">
<title>Overview of Kernel Packages</title>
@@ -143,7 +143,7 @@
<package>kernel-doc</package> — Documentation files from the kernel source. Various portions of the Linux kernel and the device drivers shipped with it are documented in these files. Installation of this package provides a reference to the options that can be passed to Linux kernel modules at load time.
</para>
<para>
- By default, these files are placed in the <filename>/usr/share/doc/kernel-doc-<replaceable>kernel_version</replaceable>/</filename> directory.
+ By default, these files are placed in the <filename>/usr/share/doc/kernel-doc-<replaceable>kernel_version</replaceable>/Documentation/</filename> directory.
</para>
</listitem>
<listitem>
@@ -182,12 +182,8 @@
<secondary>upgrading</secondary>
<tertiary>working boot media</tertiary>
</indexterm>
- <para>
- Before upgrading the kernel, it is recommended that you take some precautionary steps.
- </para>
- <para>
- First, ensure that working boot media exists for the system in case a problem occurs. If the boot loader is not configured properly to boot the new kernel, the system cannot be booted into &MAJOROS; without working boot media.
- </para>
+ <para>Before upgrading the kernel, it is recommended that you take some precautionary steps.</para>
+ <para>First, ensure that working boot media exists for the system in case a problem occurs. If the boot loader is not configured properly to boot the new kernel, you can use this media to boot into &MAJOROS;.</para>
<!--silas: the following instructions for making (USB) boot media are adapted from the RHEL6 beta Installation Guide, "Alternative Method to Make Minimal USB Boot Media" section-->
<para>
USB media often comes in the form of flash devices sometimes called <firstterm>pen drives</firstterm>, <firstterm>thumb disks</firstterm>, or <firstterm>keys</firstterm>, or as an externally-connected hard disk device. Almost all media of this type is formatted as a <systemitem class="filesystem">VFAT</systemitem> file system. You can create bootable USB media on media formatted as <systemitem class="filesystem">ext2</systemitem>, <systemitem class="filesystem">ext3</systemitem>, <systemitem class="filesystem">ext4</systemitem>, or <systemitem class="filesystem">VFAT</systemitem>.
@@ -200,49 +196,35 @@
</para>
<procedure>
<step>
- <para>
- Install the <application>SYSLINUX</application> bootloader on the USB storage device:
- </para>
- <screen><command>syslinux /dev/<replaceable>sdX1</replaceable></command></screen>
- <para>
- ...where <replaceable>sdX</replaceable> is the device name.
- </para>
+ <para>Install the <application>SYSLINUX</application> bootloader on the USB storage device:</para>
+ <screen>~]# <command>syslinux /dev/<replaceable>sdX1</replaceable></command></screen>
+ <para>...where <replaceable>sdX</replaceable> is the device name.</para>
</step>
<step>
- <para>
- Create mount points for <filename>boot.iso</filename> and the USB storage device:
- </para>
- <screen><command>mkdir /mnt/isoboot /mnt/diskboot</command></screen>
+ <para>Create mount points for <filename>boot.iso</filename> and the USB storage device:</para>
+ <screen>~]# <command>mkdir /mnt/isoboot /mnt/diskboot</command></screen>
</step>
<step>
- <para>
- Mount <filename>boot.iso</filename>:
- </para>
- <screen><command>mount -o loop boot.iso /mnt/isoboot</command></screen>
+ <para>Mount <filename>boot.iso</filename>:</para>
+ <screen>~]# <command>mount -o loop boot.iso /mnt/isoboot</command></screen>
</step>
<step>
- <para>
- Mount the USB storage device:
- </para>
- <screen><command>mount /dev/<replaceable>sdX1</replaceable> /mnt/diskboot</command></screen>
+ <para>Mount the USB storage device:</para>
+ <screen>~]# <command>mount /dev/<replaceable>sdX1</replaceable> /mnt/diskboot</command></screen>
</step>
<step>
- <para>
- Copy the <application>ISOLINUX</application> files from the <filename>boot.iso</filename> to the USB storage device:
- </para>
- <screen><command>cp /mnt/isoboot/isolinux/* /mnt/diskboot</command></screen>
+ <para>Copy the <application>ISOLINUX</application> files from the <filename>boot.iso</filename> to the USB storage device:</para>
+ <screen>~]# <command>cp /mnt/isoboot/isolinux/* /mnt/diskboot</command></screen>
</step>
<step>
- <para>
- Use the <filename>isolinux.cfg</filename> file from <filename>boot.iso</filename> as the <filename>syslinux.cfg</filename> file for the USB device:
- </para>
- <screen><command>grep -v local /mnt/isoboot/isolinux/isolinux.cfg > /mnt/diskboot/syslinux.cfg</command></screen>
+ <para>Use the <filename>isolinux.cfg</filename> file from <filename>boot.iso</filename> as the <filename>syslinux.cfg</filename> file for the USB device:</para>
+ <screen>~]# <command>grep -v local /mnt/isoboot/isolinux/isolinux.cfg > /mnt/diskboot/syslinux.cfg</command>
+ </screen>
</step>
<step>
- <para>
- Unmount <filename>boot.iso</filename> and the USB storage device:
- </para>
- <screen><command>umount /mnt/isoboot /mnt/diskboot</command></screen>
+ <para>Unmount <filename>boot.iso</filename> and the USB storage device:</para>
+ <screen>~]# <command>umount /mnt/isoboot /mnt/diskboot</command>
+ </screen>
</step>
<step>
<para>
@@ -270,7 +252,7 @@ kernel-modules-extra.x86_64 3.17.3-200.fc20 @updates<
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> package. See <xref linkend="s1-kernel-packages" /> for descriptions of the different packages.
</para>
<!-- RHEL6: the following info is probably unnecessary
- <para>In the file name, each kernel package contains the architecture for which the package was built. The format is kernel-<replaceable><variant></replaceable>-<replaceable><version></replaceable>.<replaceable><arch></replaceable>.rpm, where <replaceable><variant></replaceable> is one of either <package>PAE</package>, <package>xen</package>, and so forth. The <replaceable><arch></replaceable> is one of the following:</para>
+ <para>In the file name, each kernel package contains the architecture for which the package was built. The format is kernel-<replaceable>variant</replaceable>-<replaceable>version</replaceable>.<replaceable>arch</replaceable>.rpm, where <replaceable>variant</replaceable> is one of either <package>PAE</package>, <package>xen</package>, and so forth. The <replaceable>arch</replaceable> is one of the following:</para>
<itemizedlist>
<listitem>
<para>
@@ -368,7 +350,7 @@ kernel-modules-extra.x86_64 3.17.3-200.fc20 @updates<
<para>
At a shell prompt, change to the directory that contains the kernel RPM packages. Use <option>-i</option> argument with the <command>rpm</command> command to keep the old kernel. Do <emphasis>not</emphasis> use the <option>-U</option> option, since it overwrites the currently installed kernel, which creates boot loader problems. For example:
</para>
- <screen><command>rpm -ivh kernel-<replaceable>kernel_version</replaceable>.<replaceable>arch</replaceable>.rpm </command></screen>
+ <screen>~]# <command>rpm -ivh kernel-<replaceable>kernel_version</replaceable>.<replaceable>arch</replaceable>.rpm </command></screen>
<para>
The next step is to verify that the initial RAM disk image has been created. See <xref linkend="sec-Verifying_the_Initial_RAM_Disk_Image" /> for details.
</para>
@@ -394,7 +376,7 @@ kernel-modules-extra.x86_64 3.17.3-200.fc20 @updates<
<title>Verifying the Initial RAM Disk Image</title>
<step>
<para>
- As <systemitem class="username">root</systemitem>, list the contents in the <filename>/boot</filename> directory and find the kernel (<filename>vmlinuz-<replaceable>kernel_version</replaceable></filename>) and <filename>initramfs-<replaceable>kernel_version</replaceable></filename> with the latest (most recent) version number:
+ As <systemitem class="username">root</systemitem>, list the contents in the <filename>/boot/</filename> directory and find the kernel (<filename>vmlinuz-<replaceable>kernel_version</replaceable></filename>) and <filename>initramfs-<replaceable>kernel_version</replaceable></filename> with the latest (most recent) version number:
</para>
<example
id="ex-Ensuring_that_the_kernel_and_initramfs_versions_match">
@@ -443,15 +425,15 @@ vmlinuz-3.17.3-200.fc20.x86_64</screen>
</listitem>
</itemizedlist>
<important id="important-initrd_files_in_the__boot_directory_are_not_the_same_as_initramfs_files">
- <title>initrd files in the /boot directory are not the same as initramfs files</title>
+ <title>initrd files in the /boot/ directory are not the same as initramfs files</title>
<para>
- In the <filename class="directory">/boot</filename> directory you may find several <filename>initrd-<replaceable><kernel_version></replaceable>kdump.img</filename> files. These are special files created by the <systemitem class="service">kdump</systemitem> mechanism for kernel debugging purposes, are not used to boot the system, and can safely be ignored. For more information on <systemitem class="service">kdump</systemitem>, refer to <xref linkend="ch-kdump" />.
+ In the <filename class="directory">/boot/</filename> directory you may find several <filename>initrd-<replaceable>kernel_version</replaceable>kdump.img</filename> files. These are special files created by the <systemitem class="service">kdump</systemitem> mechanism for kernel debugging purposes, are not used to boot the system, and can safely be ignored. For more information on <systemitem class="service">kdump</systemitem>, refer to <xref linkend="ch-kdump" />.
</para>
</important>
</step>
<step performance="optional">
<para>
- (Optional) If your <filename>initramfs-<replaceable>kernel_version</replaceable></filename> file does not match the version of the latest kernel in <filename>/boot</filename>, or, in certain other situations, you may need to generate an <filename>initramfs</filename> file with the <application>Dracut</application> utility. Simply invoking <command>dracut</command> as <systemitem class="username">root</systemitem> without options causes it to generate an <filename>initramfs</filename> file in the <filename>/boot</filename> directory for the latest kernel present in that directory:
+ (Optional) If your <filename>initramfs-<replaceable>kernel_version</replaceable></filename> file does not match the version of the latest kernel in <filename>/boot</filename>, or, in certain other situations, you may need to generate an <filename>initramfs</filename> file with the <application>Dracut</application> utility. Simply invoking <command>dracut</command> as <systemitem class="username">root</systemitem> without options causes it to generate an <filename>initramfs</filename> file in the <filename class="directory">/boot/</filename> directory for the latest kernel present in that directory:
</para>
<screen>~]# <command>dracut</command></screen>
<para>
@@ -477,7 +459,7 @@ Version: dracut-037-11.git20140402.fc20
</step>
<step>
<para>
- Examine the <filename>/boot/grub2/grub.cfg</filename> configuration file to ensure that an <computeroutput>initrd <filename>/<replaceable>path</replaceable>/initramfs-<replaceable>kernel_version</replaceable>.img</filename></computeroutput> exists for the kernel version you are booting. For example:
+ Examine the <filename>/boot/grub2/grub.cfg</filename> configuration file to ensure that an <computeroutput>initrd <filename>/<replaceable>path</replaceable>/initramfs-<replaceable>kernel_version</replaceable>.img</filename></computeroutput> file exists for the kernel version you are booting. For example:
</para>
<screen>~]# <command>grep initrd /boot/grub2/grub.cfg</command>
initrd /initramfs-3.17.3-200.fc20.x86_64.img
9 years, 5 months
[system-administrators-guide] Updates to suit Fedora 20
by stephenw
commit ed1ee4e0cf9522d646dfc4f9f5d89b82bdcff352
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Nov 24 10:09:34 2014 +0100
Updates to suit Fedora 20
en-US/Manually_Upgrading_the_Kernel.xml | 83 +++++++++++++++++--------------
1 files changed, 46 insertions(+), 37 deletions(-)
---
diff --git a/en-US/Manually_Upgrading_the_Kernel.xml b/en-US/Manually_Upgrading_the_Kernel.xml
index d836b85..542bf7d 100644
--- a/en-US/Manually_Upgrading_the_Kernel.xml
+++ b/en-US/Manually_Upgrading_the_Kernel.xml
@@ -257,14 +257,15 @@
To determine which kernel packages are installed, execute the command <command>yum list installed "kernel-*"</command> at a shell prompt. The output will comprise some or all of the following packages, depending on the system's architecture, and the version numbers may differ:
</para>
<screen>~]# <command>yum list installed "kernel-*"</command>
-Loaded plugins: langpacks, presto, refresh-packagekit
+Loaded plugins: langpacks, refresh-packagekit
Installed Packages
-kernel.x86_64 3.1.0-0.rc6.git0.3.fc16 @updates-testing
-kernel.x86_64 3.1.0-0.rc9.git0.0.fc16 @updates-testing
-kernel-doc.x86_64 3.1.0-0.rc6.git0.3.fc16 @updates-testing
-kernel-doc.x86_64 3.1.0-0.rc9.git0.0.fc16 @updates-testing
-kernel-headers.x86_64 3.1.0-0.rc6.git0.3.fc16 @updates-testing
-kernel-headers.x86_64 3.1.0-0.rc9.git0.0.fc16 @updates-testing</screen>
+kernel.x86_64 3.16.7-200.fc20 @updates
+kernel.x86_64 3.17.2-200.fc20 @updates
+kernel.x86_64 3.17.3-200.fc20 @updates
+kernel-doc.noarch 3.17.3-200.fc20 @updates
+kernel-modules-extra.x86_64 3.16.7-200.fc20 @updates
+kernel-modules-extra.x86_64 3.17.2-200.fc20 @updates
+kernel-modules-extra.x86_64 3.17.3-200.fc20 @updates</screen>
<para>
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> package. See <xref linkend="s1-kernel-packages" /> for descriptions of the different packages.
</para>
@@ -395,37 +396,49 @@ kernel-headers.x86_64 3.1.0-0.rc9.git0.0.fc16 @updates-testing</screen
<para>
As <systemitem class="username">root</systemitem>, list the contents in the <filename>/boot</filename> directory and find the kernel (<filename>vmlinuz-<replaceable>kernel_version</replaceable></filename>) and <filename>initramfs-<replaceable>kernel_version</replaceable></filename> with the latest (most recent) version number:
</para>
- <screen>~]# <command>ls /boot</command>
-config-3.1.0-0.rc6.git0.3.fc16.x86_64
-config-3.1.0-0.rc9.git0.0.fc16.x86_64
-elf-memtest86+-4.20
-grub
+ <example
+ id="ex-Ensuring_that_the_kernel_and_initramfs_versions_match">
+ <title>Ensuring that the kernel and initramfs versions match</title>
+ <screen>~]# <command>ls /boot/</command>
+config-3.16.7-200.fc20.x86_64
+config-3.17.2-200.fc20.x86_64
+config-3.17.3-200.fc20.x86_64
+efi
+elf-memtest86+-5.01
+extlinux
grub2
-initramfs-3.1.0-0.rc6.git0.3.fc16.x86_64.img
-initramfs-3.1.0-0.rc9.git0.0.fc16.x86_64.img
+initramfs-0-rescue-d54d78fd40ab445a9556279010454c22.img
+initramfs-3.16.7-200.fc20.x86_64.img
+initramfs-3.17.2-200.fc20.x86_64.img
+initramfs-3.17.3-200.fc20.x86_64.img
initrd-plymouth.img
-memtest86+-4.20
-System.map-3.1.0-0.rc6.git0.3.fc16.x86_64
-System.map-3.1.0-0.rc9.git0.0.fc16.x86_64
-vmlinuz-3.1.0-0.rc6.git0.3.fc16.x86_64
-vmlinuz-3.1.0-0.rc9.git0.0.fc16.x86_64</screen>
- <para>
- The example above shows that:
- </para>
+lost+found
+memtest86+-5.01
+System.map-3.16.7-200.fc20.x86_64
+System.map-3.17.2-200.fc20.x86_64
+System.map-3.17.3-200.fc20.x86_64
+vmlinuz-0-rescue-d54d78fd40ab445a9556279010454c22
+vmlinuz-3.16.7-200.fc20.x86_64
+vmlinuz-3.17.2-200.fc20.x86_64
+vmlinuz-3.17.3-200.fc20.x86_64</screen>
+ </example>
+ <para>
+ <xref
+ linkend="ex-Ensuring_that_the_kernel_and_initramfs_versions_match" /> shows that:</para>
<itemizedlist>
<listitem>
<para>
- we have two kernels installed (or, more correctly, two kernel files are present in the <filename class="directory">/boot</filename> directory),
+ we have three kernels installed (or, more correctly, three kernel files are present in the <filename class="directory">/boot/</filename> directory),
</para>
</listitem>
<listitem>
<para>
- the latest kernel is <filename>vmlinuz-vmlinuz-3.1.0-0.rc9.git0.0.fc16.x86_64</filename>, and
+ the latest kernel is <filename>vmlinuz-3.17.3-200.fc20.x86_64</filename>, and
</para>
</listitem>
<listitem>
<para>
- an <systemitem class="filesystem">initramfs</systemitem> file matching our kernel version, <filename>initramfs-3.1.0-0.rc9.git0.0.fc16.x86_64.img</filename>, also exists.
+ an <systemitem class="filesystem">initramfs</systemitem> file matching our kernel version, <filename>initramfs-3.17.3-200.fc20.x86_64.img</filename>, also exists.
</para>
</listitem>
</itemizedlist>
@@ -445,7 +458,7 @@ vmlinuz-3.1.0-0.rc9.git0.0.fc16.x86_64</screen>
You must use the <option>--force</option> option if you want <command>dracut</command> to overwrite an existing <filename>initramfs</filename> (for example, if your <filename>initramfs</filename> has become corrupt). Otherwise <command>dracut</command> will refuse to overwrite the existing <filename>initramfs</filename> file:
</para>
<screen>~]# <command>dracut</command>
-F: Will not override existing initramfs (/boot/initramfs-3.1.0-0.rc9.git0.0.fc16.x86_64.img) without --force</screen>
+F: Will not override existing initramfs (/boot/initramfs-3.17.3-200.fc20.x86_64.img) without --force</screen>
<para>
You can create an initramfs in the current directory by calling <command>dracut <replaceable>initramfs_name</replaceable> <replaceable>kernel_version</replaceable></command>, for example:
</para>
@@ -453,16 +466,10 @@ F: Will not override existing initramfs (/boot/initramfs-3.1.0-0.rc9.git0.0.fc16
<para>
If you need to specify specific kernel modules to be preloaded, add the names of those modules (minus any file name suffixes such as <filename>.ko</filename>) inside the parentheses of the <computeroutput>add_dracutmodules="<replaceable>module</replaceable> <optional><replaceable>more_modules</replaceable></optional>"</computeroutput> directive of the <filename>/etc/dracut.conf</filename> configuration file. You can list the file contents of an <filename>initramfs</filename> image file created by dracut by using the <command>lsinitrd <replaceable>initramfs_file</replaceable></command> command:
</para>
- <screen>~]# <command>lsinitrd /boot/initramfs-3.1.0-0.rc9.git0.0.fc16.x86_64.img</command>
-/boot/initramfs-3.1.0-0.rc9.git0.0.fc16.x86_64.img: 16M
-========================================================================
-dracut-013-15.fc16
+ <screen>~]# <command>lsinitrd /boot/initramfs-3.17.3-200.fc20.x86_64.img</command>
+Image: /boot/initramfs-3.17.3-200.fc20.x86_64.img: 18M
========================================================================
-drwxr-xr-x 8 root root 0 Oct 11 20:36 .
-lrwxrwxrwx 1 root root 17 Oct 11 20:36 lib -> run/initramfs/lib
-drwxr-xr-x 2 root root 0 Oct 11 20:36 sys
-drwxr-xr-x 2 root root 0 Oct 11 20:36 proc
-lrwxrwxrwx 1 root root 17 Oct 11 20:36 etc -> run/initramfs/etc
+Version: dracut-037-11.git20140402.fc20
<lineannotation>[output truncated]</lineannotation></screen>
<para>
See <command>man dracut</command> and <command>man dracut.conf</command> for more information on options and usage.
@@ -473,8 +480,10 @@ lrwxrwxrwx 1 root root 17 Oct 11 20:36 etc -> run/initramfs/etc
Examine the <filename>/boot/grub2/grub.cfg</filename> configuration file to ensure that an <computeroutput>initrd <filename>/<replaceable>path</replaceable>/initramfs-<replaceable>kernel_version</replaceable>.img</filename></computeroutput> exists for the kernel version you are booting. For example:
</para>
<screen>~]# <command>grep initrd /boot/grub2/grub.cfg</command>
- initrd /initramfs-3.1.0-0.rc6.git0.3.fc16.x86_64.img
- initrd /initramfs-3.1.0-0.rc9.git0.0.fc16.x86_64.img</screen>
+ initrd /initramfs-3.17.3-200.fc20.x86_64.img
+ initrd /initramfs-3.17.2-200.fc20.x86_64.img
+ initrd /initramfs-3.16.7-200.fc20.x86_64.img
+ initrd /initramfs-0-rescue-d54d78fd40ab445a9556279010454</screen>
<para>
See <xref linkend="s1-kernel-boot-loader" /> for more information on how to read and update the <filename>/boot/grub2/grub.cfg</filename> file.
</para>
9 years, 5 months