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">&...
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">&...
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>