commit 806a37bf3a1680bace7cee892e9fbec67ee6b8b9 Author: Stephen Wadeley <swadeley(a)redhat.com&gt; 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