commit d1c2ee9dd428d39981c81809676757652531ae30
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Oct 14 22:07:00 2013 +0200
Adding: chapter id="ch-Configuring_NTP_using_ntpd"
en-US/Configuring_NTP_using_ntpd.xml | 868 +++++++++++++++++++++++++++++++++
en-US/System_Administrators_Guide.xml | 1 +
2 files changed, 869 insertions(+), 0 deletions(-)
---
diff --git a/en-US/Configuring_NTP_using_ntpd.xml b/en-US/Configuring_NTP_using_ntpd.xml
new file mode 100644
index 0000000..4e3c993
--- /dev/null
+++ b/en-US/Configuring_NTP_using_ntpd.xml
@@ -0,0 +1,868 @@
+<?xml version='1.0'?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+<chapter id="ch-Configuring_NTP_using_ntpd">
+ <title>Configuring NTP Using ntpd</title>
+ <!--Topics, Concepts:-->
+ <para>
+
+ </para>
+
+ <section id="s1-Introduction_to_NTP">
+ <title>Introduction to NTP</title>
+ <para>
+ 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>.
+ </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 and to update the RTC on system shut down. 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.
+ </para>
+
+ </section>
+
+ <section id="s1-NTP_Strata">
+ <title>NTP Strata</title>
+ <para>
+ <systemitem class="protocol">NTP</systemitem> servers are
classified according to their synchronization distance from the atomic clocks which are
the source of the time signals. The servers are thought of as being arranged in layers, or
strata, from 1 at the top down to 15. Hence the word stratum is used when referring to a
specific layer. Atomic clocks are referred to as Stratum 0 as this is the source, but no
Stratum 0 packet is sent on the Internet, all stratum 0 atomic clocks are attached to a
server which is referred to as stratum 1. These servers send out packets marked as Stratum
1. A server which is synchronized by means of packets marked stratum
<literal>n</literal> belongs to the next, lower, stratum and will mark its
packets as stratum <literal>n+1</literal>. Servers of the same stratum can
exchange packets with each other but are still designated as belonging to just the one
stratum, the stratum one below the best reference they are synchronized to. The des
ignation Stratum 16 is used to indicate that the server is not currently synchronized to
a reliable time source.
+ </para>
+ <para>
+ Note that by default <systemitem
class="protocol">NTP</systemitem> clients act as servers for those
systems in the stratum below them.</para>
+ <para>
+ Here is a summary of the <systemitem
class="protocol">NTP</systemitem> Strata:
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term>Stratum 0:</term>
+ <listitem>
+
+ <para>
+ Atomic Clocks and their signals broadcast over Radio and GPS
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ GPS (Global Positioning System)
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Mobile Phone Systems
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Low Frequency Radio Broadcasts
+ WWVB (Colorado, USA.), JJY-40 and JJY-60 (Japan), DCF77 (Germany), and
MSF (United Kingdom)
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ These signals can be received by dedicated devices and are usually
connected by RS-232 to a system used as an organizational or site-wide time server.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Stratum 1:</term>
+ <listitem>
+ <para>
+ Computer with radio clock, GPS clock, or atomic clock attached
+ </para>
+ </listitem>
+ </varlistentry>
+
+
+ <varlistentry>
+ <term>Stratum 2:</term>
+ <listitem>
+ <para>
+ Reads from stratum 1; Serves to lower strata
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Stratum 3:</term>
+ <listitem>
+ <para>
+ Reads from stratum 2; Serves to lower strata
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Stratum
<replaceable>n+1</replaceable>:</term>
+ <listitem>
+ <para>
+ Reads from stratum <replaceable>n</replaceable>; Serves to
lower strata
+ </para>
+ </listitem>
+ </varlistentry>
+
+<varlistentry>
+ <term>Stratum 15:</term>
+ <listitem>
+ <para>
+ Reads from stratum 14; This is the lowest stratum.
+ </para>
+ </listitem>
+ </varlistentry>
+
+
+
+ </variablelist>
+
+ <para>
+ This process continues down to Stratum 15 which is the lowest valid stratum. The
label Stratum 16 is used to indicated an unsynchronized state.</para>
+ </section>
+
+ <section id="s1-Understanding_NTP">
+ <title>Understanding NTP</title>
+ <para>
+ The version of <systemitem
class="protocol">NTP</systemitem> used by &MAJOROS; is as described
in <ulink
url="http://www.rfc-editor.org/info/rfc1305"><citetitle
pubwork="webpage">RFC 1305 Network Time Protocol (Version 3)
+ 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.
+ </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.
+ </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>
+ <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-Date_and_Time_Configuration" />. 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>
+
+<section id="s1-Understanding_the_drift_file">
+ <title>Understanding The Drift File</title>
+ <para>
+ The drift file is used to store the frequency offset between the system clock running
at its nominal frequency and the frequency required to remain in synchronization with UTC.
If present, the value contained in the drift file is read at system start and used to
correct the clock source. Use of the drift file reduces the time required to achieve a
stable and accurate time. The value is calculated, and the drift file replaced, once per
hour by <systemitem class="daemon">ntpd</systemitem>. The drift file
is replaced, rather than just updated, and for this reason the drift file must be in a
directory for which the <systemitem class="daemon">ntpd</systemitem>
has write permissions.
+ </para>
+
+</section>
+
+<section id="s1-UTC_timezones_and_DST">
+ <title>UTC, Timezones, and DST</title>
+
+ <para>
+ As <systemitem class="protocol">NTP</systemitem> is entirely
in UTC (Universal Time, Coordinated), Timezones and DST (Daylight Saving Time) are applied
locally by the system. The file <filename>/etc/localtime</filename> is a copy
of, or symlink to, a zone information file from
<filename>/usr/share/zoneinfo</filename>. The RTC may be in localtime or in
UTC, as specified by the 3rd line of <filename>/etc/adjtime</filename>, which
will be one of LOCAL or UTC to indicate how the RTC clock has been set. Users can easily
change this setting using the checkbox <guilabel>System Clock Uses
UTC</guilabel> in the <application>Date and Time</application> graphical
configuration tool. See <xref linkend="ch-Configuring_the_Date_and_Time"
/> for information on how to use that tool. Running the RTC in UTC is recommended to
avoid various problems when daylight saving time is changed.
+ </para>
+ <para>
+ The operation of <systemitem class="service">ntpd</systemitem>
is explained in more detail in the man page <filename>ntpd(8)</filename>. The
resources section lists useful sources of information. See <xref
linkend="s1-ntpd_additional-resources"/>.
+ </para>
+
+</section>
+
+<section id="s1-Authentication_options_for_NTP">
+ <title>Authentication Options for NTP</title>
+ <para>
+ <systemitem class="protocol">NTPv4</systemitem> added support
for the Autokey Security Architecture, which is based on public asymmetric cryptography
while retaining support for symmetric key cryptography. The Autokey Security Architecture
is described in <ulink
url="http://www.rfc-editor.org/info/rfc5906"><citetitle
pubwork="webpage">RFC5906 Network Time Protocol Version 4: Autokey
Specification</citetitle></ulink>. The man page
<filename>ntp_auth(5)</filename> describes the authentication options and
commands for <systemitem class="daemon">ntpd</systemitem>.
+ </para>
+ <para>
+ An attacker on the network can attempt to disrupt a service by sending <systemitem
class="protocol">NTP</systemitem> packets with incorrect time
information. On systems using the public pool of <systemitem
class="protocol">NTP</systemitem> servers, this risk is mitigated by
having more than three <systemitem class="protocol">NTP</systemitem>
servers in the list of public <systemitem
class="protocol">NTP</systemitem> servers in
<filename>/etc/ntp.conf</filename>. If only one time source is compromised or
spoofed, <systemitem class="daemon">ntpd</systemitem> will ignore
that source. You should conduct a risk assessment and consider the impact of incorrect
time on your applications and organization. If you have internal time sources you should
consider steps to protect the network over which the <systemitem
class="protocol">NTP</systemitem> packets are distributed. If you
conduct a risk assessment and conclude that the risk is acceptable, and the impact to your
applications
minimal, then you can choose not to use authentication.
+ </para>
+ <para>
+ The broadcast and multicast modes require authentication by default. If you have
decided to trust the network then you can disable authentication by using
<command>disable auth</command> directive in the
<filename>ntp.conf</filename> file. Alternatively, authentication needs to be
configured by using SHA1 or MD5 symmetric keys, or by public (asymmetric) key cryptography
using the Autokey scheme. The Autokey scheme for asymmetric cryptography is explained in
the <filename>ntp_auth(8)</filename> man page and the generation of keys is
explained in <filename>ntp-keygen(8</filename>). To implement symmetric key
cryptography, see <xref
linkend="s2_Configuring_symmetric_authentication_using_a_key" /> for an
explanation of the <option>key</option> option.
+ </para>
+</section>
+
+<section id="s1-Managing_the_time_on_Virtual_Machines">
+ <title>Managing the Time on Virtual Machines</title>
+ <para>
+Virtual machines cannot access a real hardware clock and a virtual clock is not stable
enough as the stability is dependent on the host systems work load. For this reason,
para-virtualized clocks should be provided by the virtualization application in use. On
&MAJOROS; with <application>KVM</application> the default clock source is
<option>kvm-clock</option>. See the <ulink
url="http://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualizati...
pubwork="chapter">KVM guest timing management</citetitle></ulink>
chapter of the <citetitle pubwork="book">Virtualization Host Configuration
and Guest Installation Guide</citetitle>.
+ </para>
+</section>
+
+<section id="s1-Understanding_Leap_Seconds">
+ <title>Understanding Leap Seconds</title>
+<para>
+ Greenwich Mean Time (GMT) was derived by measuring the solar day, which is dependent on
the Earth's rotation. When atomic clocks were first made, the potential for more
accurate definitions of time became possible. In 1958, International Atomic Time (TAI) was
introduced based on the more accurate and very stable atomic clocks. A more accurate
astronomical time, Universal Time 1 (UT1), was also introduced to replace GMT. The atomic
clocks are in fact far more stable than the rotation of the Earth and so the two times
began to drift apart. For this reason UTC was introduced as a practical measure. It is
kept within one second of UT1 but to avoid making many small trivial adjustments it was
decided to introduce the concept of a <firstterm>leap second</firstterm> in
order to reconcile the difference in a manageable way. The difference between UT1 and UTC
is monitored until they drift apart by more than half a second. Then only is it deemed
necessary to introduce a one second a
djustment, forward or backward. Due to the erratic nature of the Earth's rotational
speed, the need for an adjustment cannot be predicted far into the future. The decision as
to when to make an adjustment is made by the <ulink
url="http://www.iers.org"><citetitle
pubwork="webpage">International Earth Rotation and Reference Systems Service
(IERS)</citetitle></ulink>. However, these announcements are important only to
administrators of Stratum 1 servers because <systemitem
class="protocol">NTP</systemitem> transmits information about pending
leap seconds and applies them automatically.</para>
+</section>
+
+<section id="s1-Understanding_the_ntpd_Configuration_File">
+ <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>
+ 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>
+ Here follows a brief explanation of the contents of the default configuration file:
+ <variablelist>
+ <varlistentry>
+ <term>The driftfile entry</term>
+ <listitem>
+ <para>
+ A path to the drift file is specified, the default entry on &MAJOROS; is:
+ <screen>driftfile /var/lib/ntp/drift</screen>
+ If you change this be certain that the directory is writable by <systemitem
class="daemon">ntpd</systemitem>.
+ The file contains one value used to adjust the system clock frequency after every
system or service start.
+ See <link linkend="s1-Understanding_the_drift_file">Understanding
the Drift File</link> for more information.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>The access control entries</term>
+ <listitem>
+ <para>
+ The following lines setup the default access control restrictions:<screen>
+restrict default kod nomodify notrap nopeer noquery
+restrict -6 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 <option>-6</option> option is required before an <systemitem
class="protocol">IPv6</systemitem> address.
+ </para>
+ <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:
+ <screen># the administrative functions.
+restrict 127.0.0.1
+restrict -6 ::1</screen>
+ Addresses can be added underneath if specifically required by another
application. The <option>-6</option> option is required before an
<systemitem class="protocol">IPv6</systemitem> address.
+ </para>
+ <para>
+ Hosts on the local network are not permitted because of the "restrict
default" line above. To change this, for example to allow hosts from the
<systemitem class="ipaddress">192.0.2.0/24</systemitem> network to
query the time and statistics but nothing more, a line in the following format is
required:
+ <screen>restrict 192.0.2.0 mask 255.255.255.0 nomodify notrap
nopeer</screen>
+ To allow unrestricted access from a specific host, for example <systemitem
class="ipaddress">192.0.2.250/24</systemitem>, a line in the following
format is required:
+ <screen>restrict 192.0.2.250</screen>
+ A mask of <systemitem
class="ipaddress">255.255.255.255</systemitem> is applied if none is
specified.
+ </para>
+ <para>
+ The restrict commands are explained in the
<filename>ntp_acc(5)</filename> man page.
+ </para>
+
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>The public servers entry</term>
+ <listitem>
+<para>
+ By default, the <filename>ntp.conf</filename> file contains four public
server entries:
+ <screen>
+server
0.rhel.pool.ntp.org iburst
+server
1.rhel.pool.ntp.org iburst
+server
2.rhel.pool.ntp.org iburst
+server
3.rhel.pool.ntp.org iburst</screen>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <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. Refer to the explanation of the specific
commands <xref linkend="s1-Configure_NTP" />. If required, add your
commands just below the examples.</para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+</para>
+<note>
+<para>
+ When the <systemitem class="protocol">DHCP</systemitem> client
program, <application>dhclient</application>, receives a list of
<systemitem class="protocol">NTP</systemitem> servers from the
<systemitem class="protocol">DHCP</systemitem> server, it adds them
to <filename>ntp.conf</filename> and restarts the service. To disable that
feature, add <command>PEERNTP=no</command> to
<filename>/etc/sysconfig/network</filename>.
+</para>
+</note>
+</section>
+
+<section id="s1-Understanding_the_ntpd_sysconfig_file">
+ <title>Understanding the ntpd Sysconfig File</title>
+ <para>
+ The file will be read by the <systemitem
class="daemon">ntpd</systemitem> init script on service start. The
default contents is as follows:
+ <screen># Drop root to id 'ntp:ntp' by default.
+OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -g"</screen>
+ </para>
+ <para>
+ The <option>-g</option> option enables <systemitem
class="daemon">ntpd</systemitem> to ignore the offset limit of 1000s
and attempt to synchronize the time even if the offset is larger than 1000s, but only on
system start. Without that option <application>ntpd</application> will exit if
the time offset is greater than 1000s. It will also exit after system start if the service
is restarted and the offset is greater than 1000s even with the
<option>-g</option> option.
+ </para>
+ <para>
+ The <option>-p</option> option sets the path to the pid file and
<option>-u</option> sets the user and group to which the daemon should drop
the root privileges.
+ </para>
+</section>
+
+
+ <!--Topics, Tasks -->
+ <section id="s1-Disabling_chrony">
+ <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>
+To prevent it restarting at system start, issue the following command as <systemitem
class="username">root</systemitem>:
+<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>
+ </para>
+ </section>
+
+
+ <section id="s1-Checking_if_ntpd_is_installed">
+ <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 root:
+ <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>
+
+ <section id="s1-Installing_the_NTP_daemon_ntpd">
+ <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>
+ </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>
+ </para>
+</section>
+
+<section id="s1-Checking_the_status_of_NTP">
+ <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>
+ </para>
+
+
+ <para>
+ To obtain a brief status report from <systemitem
class="service">ntpd</systemitem>, issue the following command:
+ <screen>~]$ <command>ntpstat</command>
+unsynchronised
+ time server re-starting
+ polling server every 64 s</screen>
+ <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>
+ </para>
+</section>
+
+<section id="s1-Configure_the_firewall_to_allow_incoming_ntp_packets">
+ <title>Configure the Firewall to Allow Incoming NTP Packets</title>
+ <para>
+ The <systemitem class="protocol">NTP</systemitem> traffic
consists of <systemitem class="protocol">UDP</systemitem> packets on
port <literal>123</literal> and needs to be permitted through network and
host-based firewalls in order for <systemitem
class="protocol">NTP</systemitem> to function.
+ </para>
+
+ <para>
+ Check if the firewall is configured to allow incoming <systemitem
class="protocol">NTP</systemitem> traffic for clients using the
graphical <application>Firewall Configuaration</application> tool.
+ <!-- need to check this new part -->
+
+ <para>
+ To start the graphical <application>firewall-config</application>
tool, press the super key and start typing <command>firewall</command>. The
<guiicon>firewall</guiicon> icon will appear. Press enter once it is
highlighted. The <application>firewall-config</application> tool appears. You
will be prompted for your user password. <remark>CHECKME Tested on Fedora 19
</remark></para>
+ <para>
+
+ <para>
+ To start the graphical firewall configuration tool using the command line, enter
the following command as root user:
+ <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 root password
from time to time.<remark>CHECKME: Need to check if its user or root password on
Fedora 19</remark>
+ </para>
+ <para>
+ Look for the word <quote>Connected</quote> in the lower left corner.
This indicates that the <application>firewall-config</application> tool is
connected to the user space daemon, <systemitem
class="daemon">firewalld</systemitem>.
+ </para>
+
+
+ <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.
+ </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>
+ <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>.
+ </para>
+ </note>
+ </section>
+
+ <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>
+ <para>
+ Enter the port number <literal>123</literal> and select
<guilabel>udp</guilabel> from the drop-down list.
+ </para>
+ </section>
+
+</section>
+
+<section id="s1-Configure_ntpdate_servers">
+ <title>Configure ntpdate Servers</title>
+ <para>
+ The purpose of the <systemitem
class="daemon">ntpdate</systemitem> service is to set the clock during
system boot. This can be used to ensure that the services started after <systemitem
class="daemon">ntpdate</systemitem> will have the correct time and
will not observe a jump in the clock. The use of <systemitem
class="daemon">ntpdate</systemitem> and the list of step-tickers is
considered deprecated and so <application>Red Hat Enterprise Linux
6</application> uses the <option>-g</option> option to the
<command>ntpd</command> command by default and not <systemitem
class="daemon">ntpdate</systemitem>. However, the
<option>-g</option> option only enables <systemitem
class="daemon">ntpd</systemitem> to ignore the offset limit of 1000s
and attempt to synchronize the time. It does not guarantee the time will be correct when
other programs or services are started. Therefore the <systemitem
class="daemon">ntpdate</systemitem> service can be useful when
<systemitem class="daemo
n">ntpd</systemitem> is disabled or if there are services which need to be
started with the correct time and not observe a jump in the clock.
+ </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>chkconfig --list ntpdate</command>
+ntpdate 0:off 1:off 2:on 3:on 4:on 5:on 6:off</screen>
+</para>
+<para>
+ To enable the service to run at system start, issue the following command as
<systemitem class="username">root</systemitem>:
+ <screen>~]# <command>chkconfig ntpdate on</command></screen>
+</para>
+
+<para>
+ To configure <systemitem class="daemon">ntpdate</systemitem>
servers, using a text editor running as root, edit
<filename>/etc/ntp/step-tickers</filename> to include one or more host names
as follows:
+ <
screen>clock1.example.com
+clock2.example.com</screen>
+The number of servers listed is not very important as <systemitem
class="daemon">ntpdate</systemitem> will only use this to obtain the
date information once when the system is starting. If you have an internal time server
then use that host name for the first line. An additional host on the second line as a
backup is sensible. The selection of backup servers and whether the second host is
internal or external depends on your risk assessment. For example, what is the chance of
any problem affecting the fist server also affecting the second server? Would connectivity
to an external server be more likely to be available than connectivity to internal servers
in the event of a network failure disrupting access to the first server?
+</para>
+
+<para>
+ The <systemitem class="daemon">ntpdate</systemitem> service has a
file that must contain a list of <systemitem
class="protocol">NTP</systemitem> servers to be used on system start.
It is recommend to have at last four servers listed to reduce the chance of a
<quote>false ticker</quote> (incorrect time source) influencing the quality of
the time offset calculation. However, publicly accessible time sources are rarely
incorrect.</para>
+
+</section>
+
+
+<section id="s1-Configure_NTP">
+ <title>Configure NTP</title>
+ <para>
+ To change the default configuration of the <systemitem
class="protocol">NTP</systemitem> service, use a text editor running as
<systemitem class="username">root</systemitem> user to edit the
<filename>/etc/ntp.conf</filename> file. This file is installed together with
<systemitem class="daemon">ntpd</systemitem> and is configured to
use time servers from the Fedora pool by default. The man page
<filename>ntp.conf(5)</filename> describes the command options that can be
used in the configuration file apart from the access and rate limiting commands which are
explained in the <filename>ntp_acc(5)</filename> man page.
+ </para>
+
+
+ <section id="s2-Configure_Access_Control_to_an_NTP_service">
+ <title>Configure Access Control to an NTP Service</title>
+ <para>
+ To restrict or control access to the <systemitem
class="protocol">NTP</systemitem> service running on a system, make use
of the <command>restrict</command> command in the
<filename>ntp.conf</filename> file. See the commented out
example:<screen>
+# Hosts on local network are less restricted.
+#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap</screen>
+ </para>
+ <para>
+ The <command>restrict</command> command takes the following
form:</para>
+ <synopsis><command>restrict</command>
<replaceable>option</replaceable></synopsis>
+ <para>where <replaceable>option</replaceable> is one or more of:
+ <itemizedlist>
+ <listitem>
+ <para>
+ <option>ignore</option> — All packets will be ignored,
including <systemitem class="protocol">ntpq</systemitem> and
<systemitem class="protocol">ntpdc</systemitem>
queries.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <option>kod</option> — a
<quote>Kiss-o'-death</quote> packet is to be sent to reduce unwanted
queries.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <option>limited</option> — do not respond to time service
requests if the packet violates the rate limit specified by the
<command>discard</command> command. <systemitem
class="protocol">ntpq</systemitem> and <systemitem
class="protocol">ntpdc</systemitem> queries are not
affected.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <option>lowpriotrap</option> — traps set by matching hosts
to be low priority.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <option>nomodify</option> — prevents any changes to the
configuration.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <option>noquery</option> — prevents <systemitem
class="protocol">ntpq</systemitem> and <systemitem
class="protocol">ntpdc</systemitem> queries, but not time queries, from
being answered.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <option>nopeer</option> — prevents a peer association
being formed.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <option>noserve</option> — deny all packets except
<systemitem class="protocol">ntpq</systemitem> and <systemitem
class="protocol">ntpdc</systemitem> queries.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <option>notrap</option> — prevents <systemitem
class="protocol">ntpdc</systemitem> control message protocol
traps.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <option>notrust</option> — deny packets that are not
cryptographically authenticated.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <option>ntpport</option> — modify the match algorithm to
only apply the restriction if the source port is the standard <systemitem
class="protocol">NTP</systemitem> <systemitem
class="protocol">UDP</systemitem> port
<literal>123</literal>.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <option>version</option> — deny packets that do not match
the current <systemitem class="protocol">NTP</systemitem>
version.</para>
+ </listitem>
+ </itemizedlist>
+
+ </para>
+ </section>
+
+ <section id="s2_Configure_Rate_Limiting_Access_to_an_NTP_service ">
+ <title>Configure Rate Limiting Access to an NTP Service</title>
+ <para>
+ To rate limit access to the <systemitem
class="protocol">NTP</systemitem> service running on a system, make use
of the <command>discard</command> command in the
<filename>ntp.conf</filename> file. See the commented out
example:<screen>
+# Hosts on local network are less restricted.
+#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap</screen>
+</para>
+
+ <para>
+ The <command>discard</command> command takes the following
form:</para>
+ <synopsis><command>discard</command>
<replaceable>option</replaceable>
<replaceable>argument</replaceable></synopsis>
+ <para>
+ where <replaceable>option</replaceable> is one or more of:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <option>average</option> — specifies the minimum average
packet spacing to be permitted, it accepts an argument in
<inlineequation><mathphrase>log<subscript>2</subscript></mathphrase></inlineequation>
seconds. The default value is 3
(<inlineequation><mathphrase>2<superscript>3</superscript></mathphrase></inlineequation>
equates to 8 seconds).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <option>minimum</option> — specifies the minimum packet spacing
to be permitted, it accepts an argument in
<inlineequation><mathphrase>log<subscript>2</subscript></mathphrase></inlineequation>
seconds. The default value is 1
(<inlineequation><mathphrase>2<superscript>1</superscript></mathphrase></inlineequation>
equates to 2 seconds).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <option>monitor</option> — specifies the discard probability for
packets once the permitted rate limits have been exceeded. The default value is 3000
seconds. This option is intended for servers that receive 1000 or more requests per
second.
+ </para>
+ </listitem>
+ </itemizedlist>
+</section>
+
+<section id="s2_Adding_a_Peer_Address">
+ <title>Adding a Peer Address</title>
+ <para>
+ To add the address of a peer, that is to say, the address of a server running an
<systemitem class="protocol">NTP</systemitem> service of the same
stratum, make use of the <command>peer</command> command in the
<filename>ntp.conf</filename> file.
+ </para>
+<para>
+ The <command>peer</command> command takes the following form:</para>
+<synopsis><command>peer</command>
<replaceable>address</replaceable></synopsis>
+ <para>
+ where <replaceable>address</replaceable> is an <systemitem
class="protocol">IP</systemitem> unicast address or a <systemitem
class="protocol">DNS</systemitem> resolvable name. The address must
only be that of a system known to be a member of the same stratum. Peers should have at
least one time source that is different to each other. Peers are normally systems under
the same administrative control.
+ </para>
+ </section>
+
+<section id="s2_Adding_a_Server_Address">
+ <title>Adding a Server Address</title>
+ <para>
+ To add the address of a server, that is to say, the address of a server running an
<systemitem class="protocol">NTP</systemitem> service of a higher
stratum, make use of the <command>server</command> command in the
<filename>ntp.conf</filename> file.
+</para>
+<para>
+ The <command>server</command> command takes the following
form:</para>
+<synopsis><command>server</command>
<replaceable>address</replaceable></synopsis>
+ <para>
+ where <replaceable>address</replaceable> is an <systemitem
class="protocol">IP</systemitem> unicast address or a <systemitem
class="protocol">DNS</systemitem> resolvable name.
+ The address of a remote reference server or local reference clock from which
packets are to be received.
+ </para>
+ </section>
+
+
+ <section id="s2_Adding_a_Broadcast_or_Mutlticast_Server_Address">
+ <title>Adding a Broadcast or Multicast Server Address</title>
+ <para>
+ To add a broadcast or multicast address for sending, that is to say, the address to
broadcast or multicast <systemitem class="protocol">NTP</systemitem>
packets to, make use of the <command>broadcast</command> command in the
<filename>ntp.conf</filename> file.
+ </para>
+ <para>
+ The broadcast and multicast modes require authentication by default. See <xref
linkend="s1-Authentication_options_for_NTP" />.</para>
+<para>
+ The <command>broadcast</command> command takes the following
form:</para>
+<synopsis><command>broadcast</command>
<replaceable>address</replaceable></synopsis>
+ <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="
http://www.rfc-editor.org/info/rfc2365"><citetitle
pubwork="webpage">RFC 2365 Administratively Scoped IP
Multicast</citetitle></ulink>.
+ </para>
+ </section>
+
+
+ <section id="s2_Adding_a_Manycast_Client_Address">
+ <title>Adding a Manycast Client Address</title>
+ <para>
+ To add a manycast client address, that is to say, to configure a multicast address
to be used for <systemitem class="protocol">NTP</systemitem> server
discovery, make use of the <command>manycastclient</command> command in the
<filename>ntp.conf</filename> file.
+ </para>
+<para>
+ The <command>manycastclient</command> command takes the following
form:</para>
+ <synopsis><command>manycastclient</command>
<replaceable>address</replaceable></synopsis>
+ <para>
+ where <replaceable>address</replaceable> is an <systemitem
class="protocol">IP</systemitem> multicast address from which packets
are to be received.
+ The client will send a request to the address and select the best servers from
the responses and ignore other servers. <systemitem
class="protocol">NTP</systemitem> communication then uses unicast
associations, as if the discovered <systemitem
class="protocol">NTP</systemitem> servers were listed in
<filename>ntp.conf</filename>.
+ </para>
+ <para>
+ This command configures a system to act as an <systemitem
class="protocol">NTP</systemitem> client. Systems can be both client
and server at the same time.
+ </para>
+ </section>
+
+<section id="s2_Adding_a_Broadcastclient_Address">
+ <title>Adding a Broadcast Client Address</title>
+ <para>
+ To add a broadcast client address, that is to say, to configure a broadcast address
to be monitored for broadcast <systemitem
class="protocol">NTP</systemitem> packets, make use of the
<command>broadcastclient</command> command in the
<filename>ntp.conf</filename> file.
+ </para>
+<para>
+ The <command>broadcastclient</command> command takes the following
form:</para>
+<synopsis><command>broadcastclient</command></synopsis>
+ <para>
+ Enables the receiving of broadcast messages. Requires authentication by default.
See <xref linkend="s1-Authentication_options_for_NTP" />.
+ </para>
+ <para>
+ This command configures a system to act as an <systemitem
class="protocol">NTP</systemitem> client. Systems can be both client
and server at the same time.
+ </para>
+
+ </section>
+
+<section id="s2_Adding_a_manycastserver_Address">
+ <title>Adding a Manycast Server Address</title>
+ <para>
+ To add a manycast server address, that is to say, to configure an address to allow
the clients to discover the server by multicasting <systemitem
class="protocol">NTP</systemitem> packets, make use of the
<command>manycastserver</command> command in the
<filename>ntp.conf</filename> file.
+ </para>
+<para>
+ The <command>manycastserver</command> command takes the following
form:</para>
+<synopsis><command>manycastserver</command>
<replaceable>address</replaceable></synopsis>
+ <para>
+ Enables the sending of multicast messages. Where
<replaceable>address</replaceable> is the address to multicast to. This should
be used together with authentication to prevent service disruption.
+ </para>
+ <para>
+ This command configures a system to act as an <systemitem
class="protocol">NTP</systemitem> server. Systems can be both client
and server at the same time.
+ </para>
+ </section>
+
+
+<section id="s2_Adding_a_multicastclient_Address">
+ <title>Adding a Multicast Client Address</title>
+ <para>
+ To add a multicast client address, that is to say, to configure a multicast address
to be monitored for multicast <systemitem
class="protocol">NTP</systemitem> packets, make use of the
<command>multicastclient</command> command in the
<filename>ntp.conf</filename> file.
+ </para>
+<para>
+ The <command>multicastclient</command> command takes the following
form:</para>
+<synopsis><command>multicastclient</command>
<replaceable>address</replaceable></synopsis>
+<para>
+ Enables the receiving of multicast messages. Where
<replaceable>address</replaceable> is the address to subscribe to. This should
be used together with authentication to prevent service disruption.
+ </para>
+ <para>
+ This command configures a system to act as an <systemitem
class="protocol">NTP</systemitem> client. Systems can be both client
and server at the same time.
+ </para>
+
+ </section>
+
+<section id="s2_Configuring_the_burst_option">
+ <title>Configuring the Burst Option</title>
+ <para>
+ Using the <command>burst</command> option against a public server is
considered abuse. Do not use this option with public <systemitem
class="protocol">NTP</systemitem> servers. Use it only for applications
within your own organization.
+ </para>
+ <para>
+ To increase the average quality of time offset statistics, add the following option
to the end of a server command:
+ </para>
+
+ <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.
+ </para>
+</section>
+
+<section id="s2_Configuring_the_iburst_option">
+ <title>Configuring the iburst Option</title>
+ <para>
+ To improve the time taken for initial synchronization, add the following option to
the end of a server command:
+ </para>
+
+ <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.
+ </para>
+</section>
+
+<section id="s2_Configuring_symmetric_authentication_using_a_key">
+ <title>Configuring Symmetric Authentication Using a Key</title>
+ <para>
+ To configure symmetric authentication using a key, add the following option to the
end of a server or peer command:
+ </para>
+
+ <synopsis><command>key</command>
<replaceable>number</replaceable></synopsis>
+ <para>
+ where <replaceable>number</replaceable> is in the range
<literal>1</literal> to <literal>65534</literal> inclusive.
+ This option enables the use of a <firstterm>message authentication
code</firstterm> (<acronym>MAC</acronym>) in packets. This option is for
use with the <command>peer</command>, <command>server</command>,
<command>broadcast</command>, and
<command>manycastclient</command> commands.
+ </para>
+ <para>
+ The option can be used in the <filename>/etc/ntp.conf</filename> file as
follows:
+ <screen>server 192.168.1.1 key 10
+broadcast 192.168.1.255 key 20
+manycastclient 239.255.254.254 key 30</screen>
+ </para>
+ <para>
+ See also <xref linkend="s1-Authentication_options_for_NTP" />.
+ </para>
+</section>
+
+
+<section id="s2_Configuring_the_poll_interval">
+ <title>Configuring the Poll Interval</title>
+ <para>
+ To change the default poll interval, add the following options to the end of a server
or peer command:
+ </para>
+ <synopsis><command>minpoll</command>
<replaceable>value</replaceable> and <command>maxpoll</command>
<replaceable>value</replaceable></synopsis>
+ <para>
+ Options to change the default poll interval, where the interval in seconds will be
calculated by raising 2 to the power of <replaceable>value</replaceable>, in
other words, the interval is expressed in
<inlineequation><mathphrase>log<subscript>2</subscript></mathphrase></inlineequation>
seconds. The default <option>minpoll</option> value is 6,
<inlineequation><mathphrase>2<superscript>6</superscript></mathphrase></inlineequation>
equates to 64s. The default value for <option>maxpoll</option> is 10, which
equates to 1024s. Allowed values are in the range 3 to 17 inclusive, which equates to 8s
to 36.4h respectively. These options are for use with the
<command>peer</command> or <command>server</command>. Setting a
shorter <option>maxpoll</option> may improve clock accuracy.
+ </para>
+</section>
+
+
+<section id="s2_Configuring_server_preference">
+ <title>Configuring Server Preference</title>
+ <para>
+ To specify that a particular server should be preferred above others of similar
statistical quality, add the following option to the end of a server or peer command:
+ </para>
+ <synopsis><command>prefer</command></synopsis>
+ <para>
+ Use this server for synchronization in preference to other servers of similar
statistical quality. This option is for use with the <command>peer</command>
or <command>server</command> commands.
+ </para>
+</section>
+
+<section id="s2_Configuring_the_Time-To-Live_for_NTP_Packets">
+ <title>Configuring the Time-to-Live for NTP Packets</title>
+ <para>
+ To specify that a particular <firstterm>time-to-live</firstterm>
(<acronym>TTL</acronym>) value should be used in place of the default, add the
following option to the end of a server or peer command:
+ </para>
+ <synopsis><command>ttl</command>
<replaceable>value</replaceable></synopsis>
+ <para>
+ Specify the time-to-live value to be used in packets sent by broadcast servers and
multicast <systemitem class="protocol">NTP</systemitem> servers.
Specify the maximum time-to-live value to use for the <quote>expanding ring
search</quote> by a manycast client. The default value is
<literal>127</literal>.
+ </para>
+</section>
+
+<section id="s2_Configuring_The_Version_of_NTP_to_use">
+ <title>Configuring the NTP Version to Use</title>
+ <para>
+ To specify that a particular version of <systemitem
class="protocol">NTP</systemitem> should be used in place of the
default, add the following option to the end of a server or peer command:
+ </para>
+ <synopsis><command>version</command>
<replaceable>value</replaceable></synopsis>
+ <para>
+ Specify the version of <systemitem
class="protocol">NTP</systemitem> set in created <systemitem
class="protocol">NTP</systemitem> packets. The value can be in the
range <literal>1</literal> to <literal>4</literal>. The default is
<literal>4</literal>.
+ </para>
+ </section>
+ </section>
+
+<section id="s1-Configuring_the_hardware_clock_update">
+ <title>Configuring the Hardware Clock Update</title>
+ <para>
+ To configure the system clock to update the hardware clock once after executing
<application>ntpdate</application>, add the following line to
<filename>/etc/sysconfig/ntpdate</filename>:
+ <programlisting>SYNC_HWCLOCK=yes</programlisting>
+ </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>
+ </para>
+
+ </section>
+
+ <section id="s1-Configuring_Clock_Sources">
+ <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>
+clocksource0]$ <command>cat available_clocksource</command>
+kvm-clock tsc hpet acpi_pm
+clocksource0]$ <command>cat current_clocksource</command>
+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>
+ The available clock source is architecture dependent. <!-- See the Kernel
Parameters documentation
<filename>/usr/share/doc/kernel-doc-*/Documentation/kernel-parameters.txt</filename>.
Note that this documentation is not installed by default. I think normal users do not need
to know this. See s2-ntpd-docs-optional-inst -->
+ </para>
+ </section>
+
+
+
+
+<!--Topics, Reference-->
+ <section id="s1-ntpd_additional-resources">
+
+<title>Additional Resources</title>
+ <para>
+ The following sources of information provide additional resources regarding
<systemitem class="protocol">NTP</systemitem> and <systemitem
class="service">ntpd</systemitem>.
+ </para>
+<section id="s2-ntpd-docs-inst">
+ <title>Installed Documentation</title>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <filename>ntpd(8)</filename> man page — Describes <systemitem
class="service">ntpd</systemitem> in detail, including the command line
options.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>ntp.conf(5)</filename> man page — Contains information on
how to configure associations with servers and peers.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>ntpq(8)</filename> man page — Describes the <systemitem
class="protocol">NTP</systemitem> query utility for monitoring and
querying an <systemitem class="protocol">NTP</systemitem> server.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>ntpdc(8)</filename> man page — Describes the <systemitem
class="daemon">ntpd</systemitem> utility for querying and changing the
state of <systemitem class="daemon">ntpd</systemitem>.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>ntp_auth(5)</filename> man page — Describes authentication
options, commands, and key management for <systemitem
class="service">ntpd</systemitem>.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>ntp_keygen(8)</filename> man page — Describes generating
public and private keys for <systemitem
class="service">ntpd</systemitem>.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>ntp_acc(5)</filename> man page — Describes access control
options using the <command>restrict</command> command.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>ntp_mon(5)</filename> man page — Describes monitoring
options for the gathering of statistics.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>ntp_clock(5)</filename> man page — Describes commands for
configuring reference clocks.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>ntp_misc(5)</filename> man page — Describes miscellaneous
options.</para>
+ </listitem>
+ </itemizedlist>
+</section>
+
+<section id="s2-ntpd_useful-websites">
+ <title>Useful Websites</title>
+ <variablelist>
+ <varlistentry>
+<term><ulink
url="http://doc.ntp.org/"/></term>
+<listitem>
+<para>
+The NTP Documentation Archive
+</para>
+</listitem>
+</varlistentry>
+ <varlistentry>
+<term><ulink
url="http://www.eecis.udel.edu/~mills/ntp.html"/></term>
+<listitem>
+<para>
+Network Time Synchronization Research Project.
+</para>
+</listitem>
+</varlistentry>
+ <varlistentry>
+<term><ulink
url="http://www.eecis.udel.edu/~mills/ntp/html/manyopt.html"/&g...
+<listitem>
+<para>
+Information on Automatic Server Discovery in <systemitem
class="protocol">NTPv4</systemitem>.
+</para>
+</listitem>
+</varlistentry>
+</variablelist>
+ </section>
+
+</section>
+
+</chapter>
diff --git a/en-US/System_Administrators_Guide.xml
b/en-US/System_Administrators_Guide.xml
index 3b8f11d..5e12a95 100644
--- a/en-US/System_Administrators_Guide.xml
+++ b/en-US/System_Administrators_Guide.xml
@@ -18,6 +18,7 @@
<xi:include href="Configuring_the_Language_and_Keyboard.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Configuring_the_Date_and_Time.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Configuring_NTP_using_the_Chrony_suite.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Configuring_NTP_using_ntpd.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Configuring_PTP_using_ptp4l.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Managing_Users_and_Groups.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<!-- Gaining Privileges -->