8:20 a.m.
commit 806a37bf3a1680bace7cee892e9fbec67ee6b8b9
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Thu Jun 27 20:40:58 2013 +0200
Going to use "chrony" with lower case "c" except at the beginning
of a sentence.
en-US/Configuring_NTP_using_the_Chrony_suite.xml | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
---
diff --git a/en-US/Configuring_NTP_using_the_Chrony_suite.xml
b/en-US/Configuring_NTP_using_the_Chrony_suite.xml
index 4104a03..a7914a3 100644
--- a/en-US/Configuring_NTP_using_the_Chrony_suite.xml
+++ b/en-US/Configuring_NTP_using_the_Chrony_suite.xml
@@ -16,9 +16,9 @@
There is a choice between the daemons <systemitem
class="daemon">ntpd</systemitem> and <systemitem
class="daemon">chronyd</systemitem>, which are available from the repos
in the <package>ntp</package> and <package>chrony</package>
packages respectively. This section describes the use of the
<application>chrony</application> suite of utilities to update the daemon on
systems that do not fit into the conventional permanently networked, always on, dedicated
server category.
</para>
<section id="sect-Introduction_to_the_chrony_suite">
- <title>Introduction To The Chrony Suite</title>
+ <title>Introduction To The chrony Suite</title>
<para>
- <application>Chrony</application> consists of <systemitem
class="daemon">chronyd</systemitem>, a daemon that runs in user space,
and <application>chronyc</application>, a command line program for making
adjustments to <systemitem class="daemon">chronyd</systemitem>.
Systems which are not permanently connected, or not permanently powered up, take a
relatively long time to adjust their system clocks using the <systemitem
class="protocol">NTP</systemitem> time protocol. This is because many
small corrections are made based on observations of the clocks drift and offset.
Temperature changes, which may be significant when powering up a system, affect the
stability of hardware clocks. Although adjustments begin within a few milliseconds of
booting a system, acceptable accuracy may take anything from ten seconds from a warm
restart to a number of hours depending on your requirements, operating environment and
hardware. <application>Chrony</application> is a different implementat
ion of the <systemitem class="protocol">NTP</systemitem> protocol
than <systemitem class="daemon">ntpd</systemitem>, it can adjust the
system clock more rapidly.
+ <application>Chrony</application> consists of <systemitem
class="daemon">chronyd</systemitem>, a daemon that runs in user space,
and <application>chronyc</application>, a command line program for making
adjustments to <systemitem class="daemon">chronyd</systemitem>.
Systems which are not permanently connected, or not permanently powered up, take a
relatively long time to adjust their system clocks using the <systemitem
class="protocol">NTP</systemitem> time protocol. This is because many
small corrections are made based on observations of the clocks drift and offset.
Temperature changes, which may be significant when powering up a system, affect the
stability of hardware clocks. Although adjustments begin within a few milliseconds of
booting a system, acceptable accuracy may take anything from ten seconds from a warm
restart to a number of hours depending on your requirements, operating environment and
hardware. <application>chrony</application> is a different implementat
ion of the <systemitem class="protocol">NTP</systemitem> protocol
than <systemitem class="daemon">ntpd</systemitem>, it can adjust the
system clock more rapidly.
</para>
</section>
@@ -114,7 +114,7 @@ Things <systemitem
class="daemon">ntpd</systemitem> can do that <systemitem clas
<section id="sect-Understanding_chronyd">
<title>Understanding chronyd</title>
<para>
- The <application>Chrony</application> daemon, <systemitem
class="daemon">chronyd</systemitem>, running in user space, makes
adjustments to the system clock which is running in the kernel. It does this by consulting
external time sources, using the <systemitem
class="protocol">NTP</systemitem> protocol, when ever network access
allows it to do so. When external references are not available, <systemitem
class="daemon">chronyd</systemitem> will use the last calculated drift
stored in the drift file. It can also be commanded manually to make corrections, by
<application>chronyc</application>.
+ The <application>chrony</application> daemon, <systemitem
class="daemon">chronyd</systemitem>, running in user space, makes
adjustments to the system clock which is running in the kernel. It does this by consulting
external time sources, using the <systemitem
class="protocol">NTP</systemitem> protocol, when ever network access
allows it to do so. When external references are not available, <systemitem
class="daemon">chronyd</systemitem> will use the last calculated drift
stored in the drift file. It can also be commanded manually to make corrections, by
<application>chronyc</application>.
</para>
</section>
@@ -175,7 +175,7 @@ Optionally specify a host, subnet, or network from which to allow
<systemitem cl
<term>cmdallow</term>
<listitem>
<para>
- This is similar to the <command>allow</command> directive (see
section allow), except that it allows control access (rather than <systemitem
class="protocol">NTP</systemitem> client access) to a particular subnet
or host. (By ’control access’ is meant that <application>chronyc</application>
can be run on those hosts and successfully connect to <systemitem
class="daemon">chronyd</systemitem> on this computer.) The syntax is
identical. There is also a <command>cmddeny</command> all directive with
similar behaviour to the <command>cmdallow</command> all directive.
</para>
+ This is similar to the <command>allow</command> directive (see
section allow), except that it allows control access (rather than <systemitem
class="protocol">NTP</systemitem> client access) to a particular subnet
or host. (By <quote>control access</quote> is meant that
<application>chronyc</application> can be run on those hosts and successfully
connect to <systemitem class="daemon">chronyd</systemitem> on this
computer.) The syntax is identical. There is also a <command>cmddeny</command>
all directive with similar behaviour to the <command>cmdallow</command> all
directive. </para>
</listitem>
</varlistentry>
@@ -199,7 +199,7 @@ Optionally specify a host, subnet, or network from which to allow
<systemitem cl
<term>local</term>
<listitem>
<para>
- The <command>local</command> keyword is used to allow
<systemitem class="daemon">chronyd</systemitem> to appear
synchronized to real time (from the viewpoint of clients polling it), even if it has no
current synchronization source. This option is normally used on computers in an isolated
network, where several computers are required to synchronize to one other, this being the
"master" which is kept vaguely in line with real time by manual
input.</para>
+ The <command>local</command> keyword is used to allow
<systemitem class="daemon">chronyd</systemitem> to appear
synchronized to real time (from the viewpoint of clients polling it), even if it has no
current synchronization source. This option is normally used on computers in an isolated
network, where several computers are required to synchronize to one other, this being the
<quote>master</quote> which is kept vaguely in line with real time by manual
input.</para>
<para>
An example of the command is:
<screen>local stratum 10</screen>
@@ -858,7 +858,7 @@ This is the estimated error bounds on Freq (again in parts per
million).
</section>
<section
id="sect-Setting_up_chrony_for_a_system_which_is_infrequently_connected">
- <title>Setting Up Chrony For A System Which Is Infrequently
Connected</title>
+ <title>Setting Up chrony For A System Which Is Infrequently
Connected</title>
<para>
This example is intended for systems which use dial-on-demand connections. The normal
configuration should be sufficient for mobile and virtual devices which connect
intermittently. First, review and confirm that the default settings in the
<filename>/etc/chrony.conf</filename> are similar to the following:
<screen>driftfile /var/lib/chrony/drift