* Allow ntpq &1 associd use without preceding association-fetching.
+* Documentation updates from Dave Mills.
(4.2.7p101) 2010/12/22 Released by Harlan Stenn <stenn@ntp.org>
* from 4.2.6p3-RC12: Upgrade to libopts 34.0.9 from AutoGen 5.11.6pre7.
* from 4.2.6p3-RC12: Relax minimum Automake version to 1.10 with updated
<img src="pic/alice44.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Our resident cryptographer; now you see him, now you don't.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->15-Dec-2010 2:56<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->22-Dec-2010 21:55<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<dd><span class="style1">Note: In the latest Autokey version, this option is deprecated. See the <a href="autokey.html">Autokey Public-Key Authentication</a> page for further information.</span></a>
<dt> </dt>
<dt><tt>ident <i>group</i></tt></dt>
- <dd>Specifies the string used in retrieving the identity files generated by the <tt>ntp-keygen</tt> program with the <tt>-i <i>group</i></tt> option.</dd>
+ <dd>Specifies the optional string used in retrieving the identity files generated by the <tt>ntp-keygen</tt> program with the <tt>-i <i>group</i></tt> option.</dd>
<dt><tt>pw <i>password</i></tt></dt>
<dd>Specifies the password to decrypt files previously encrypted by the <tt>ntp-keygen</tt> program with the <tt>-p</tt> option.</dd>
<dt><tt>randfile <i>file</i></tt></dt>
<body>
<h3>Autokey Public-Key Authentication</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->19-Dec-2010 22:23<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->23-Dec-2010 6:59<!-- #EndDate -->
UTC</p>
<hr>
<h4>Table of Contents</h4>
<p> Autokey uses industry standard X.509 public certificates, which can be produced by commercial services, utility programs in the OpenSSL software library, and the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program in the NTP software distribution. A certificate includes the subject name of the client, the issuer name of the server, the public key of the server and the time period over which the the server public and private keys are valid. All Autokey hosts have a self-signed certificate with the Autokey name as both the subject and issuer. During the protocol, additional certificates are produced with the Autokey host name as subject and the host that signs the certificate as issuer.</p>
<p>There are two timeouts associated with the Autokey scheme. The <em>key list timeout</em> is set by the <tt>automax</tt> command, which specifies the interval between generating new key lists by the client. The default timeout of about 1.1 hr is appropriate for the majority of configurations and ordinarily should not be changed. The <em>revoke timeout</em> is set by the <tt>revoke</tt> command, which specifies the interval between generating new server private values. It is intended to reduce the vulnerability to cryptanalysis; however, new values require the server to encrypt each client cookie separately. The default timeout of about 36 hr is appropriate for most servers, but might be too short for national time servers.</p>
<h4 id="cert">Autokey Subnets</h4>
-<p> An Autokey subnet consists of a collection of hosts configured as an acyclic, directed tree with roots one or more trusted hosts (THs) operating at the lowest stratum of the subnet. The THs are synchronized directly or indirectly to national time services via trusted means, such as radio, satellite or telephone modem, or an NTP secure group as described in the next section. Autokey hosts operate as servers, clients or both at the same time.</p>
-<p>A certificate trail is a sequence of certificates, each signed by a host one step closer to the THs and terminating at the self-signed certificate of a TH. In general, NTP servers operate as certificate authorities (CAs) to sign certificates provided by its clients. The CAs include the THs and those group servers with dependent clients. In order for the signature to succeed, the client certificate valid period must begin within the valid period of the server certificate. If the server period begins later than the client period, the client certificate has expired; if the client period begins later than the server period, the server certificate has expired. While the certificate trail authenticates each host on the trail to the THs, it does not validate the time values themselves. Ultimately, this is determined by the NTP on-wire protocool.</p>
-<dd class="style1">The requirement that the NTP subnet be acyclic means that, if peers are configured with each other in symmetric modes, each must be a TH.</dd>
-<p>The Autokey protocol runs for each association separately. During the protocol the client recursively obtains all the certificates on the trail to a TH, saving each in a cache ordered from most recent to oldest. If an expired certificate is found, it is invalidated and marked for later replacement. As the client certificate itself is not involved in the certificate trail, it can only be declared valid or expired when the server signs it. </p>
+<p> An Autokey subnet consists of a collection of hosts configured as an acyclic, directed tree with roots one or more trusted hosts (THs) operating at the lowest stratum of the subnet. The THs are synchronized directly or indirectly to national time services via trusted means, such as radio, satellite or telephone modem, or a trusted agent (TA) of a host group, as described below.</p>
+<dl>
+ <dd><span class="style1">The requirement that the NTP subnet be acyclic means that, if peers are configured with each other in symmetric modes, each must be a TH.</span></dd>
+</dl>
+<p>A certificate trail is a sequence of certificates, each signed by a host one step closer to the THs and terminating at the self-signed certificate of a TH. NTP servers operate as certificate authorities (CAs) to sign certificates provided by their clients. The CAs include the TAs of the host group and those subnet servers with dependent clients.</p>
+<p> In order for the signature to succeed, the client certificate valid period must begin within the valid period of the server certificate. If the server period begins later than the client period, the client certificate has expired; if the client period begins later than the server period, the server certificate has expired.</p>
+<p>The Autokey protocol runs for each association separately; but, while the certificate trail authenticates each host on the trail to the THs, it does not validate the time values themselves. Ultimately, this is determined by the NTP on-wire protocool. During the protocol, the client recursively obtains the certificates on the trail to a TH, saving each in a cache ordered from most recent to oldest. If an expired certificate is found, it is invalidated and marked for later replacement. As the client certificate itself is not involved in the certificate trail, it can only be declared valid or expired when the server signs it. </p>
<p>The certificates derived from each association are combined in the cache with duplicates suppressed. If it happens that two different associations contribute certificates to the cache, a certificate on the trail from one association could expire before any on another trail. In this case the remaining trails will survive until the expired certificate is replaced. Once saved in the cache, a certificate remains valid until it expires or is replaced by a new one.</p>
<p> It is important to note that the certificate trail is validated only at startup when an association is mobilized. Once validated in this way, the server remains valid until it is demobilized, even if certificates on the trail to the THs expire.</p>
<p>Example</p>
<div align="center"><img src="pic/flt8.gif" alt="gif">
<p>Figure 1. Example Configuration</p>
</div>
-<p>Figure 1 shows an example configuration with three NTP subnets, Alice, Helen and Carol. Hosts A and B are THs of Alice, host R is the TH of Helen and host X is the TH of Carol. Assume that all associations are client/server; so, for example, TH X has two mobilized associations, one to Alice host C and the other to Carol host S. While not shown in the figure, Alice hosts A and B could configure symmetric mode associations between them for redundancy and backup.</p>
+<p>Figure 1 shows an example configuration with three NTP subnets, Alice, Helen and Carol. Alice and Helen are host groups for Carol with TA C belonging to Alice and TA S belonging to Helen. Hosts A and B are THs of Alice, host R is the TH of Helen and host X is the TH of Carol. Assume that all associations are client/server, TH X has two mobilized associations, one to Alice TA host C and the other to Carol TA host S. While not shown in the figure, Alice hosts A and B could configure symmetric mode associations between them for redundancy and backup.</p>
<p>Note that host D cetificate trail is D→C→A or D→C→B, depending on the particular order the trails are built. Host Y certificate trail is only Y→X, since X is a TH. Host X has two cetficate trails X→C→A or X→C→B, and X→S→R.</p>
<h4 id="group">NTP Secure Groups</h4>
<p>NTP security groups are an extension of the NTP subnets described in the previous section. They include in addition to certificate trails one or another identity schemes described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page. NTP secure groups are used to define cryptographic compartments and security
hierarchies. The identity scheme insures that the server is authentic and not victim of masquerade by an intruder acting as a middleman.</p>
-<p> As in NTP subnet, NTP secure groups are configured as an acyclic tree rooted on the THs. The THs are at the lowest stratum of the secure group; they and possibly other hosts in the group run the identity exchange. All group hosts construct an unbroken certificate trail from each host, possibly via intermediate hosts, and ending at a TH of that group. The TH verifies authenticity as a client of a serverin another group.</p>
-<p> For secure group servers, the string specified by the <tt>-i</tt> option of the <tt>ntp-keygen</tt> program is the name of the secure group. For secure group servers this name must match the <tt>ident</tt> option
- of the <tt>crypto</tt> command. For secure group clients, this name must match the <tt>ident</tt> option of the <tt>server</tt> command. This name is also used in the identity keys and parameters file names. The file naming conventions are described on
- the <a href="keygen.html">ntp-keygen</a> page.</p>
-<dd><span class="style1">In the latest Autokey version, the host name and group name are independent of each other and the <tt>host</tt> option of the <tt>crypto</tt> command is deprecated. When compatibility with older versions is required, specify the same name for both the <tt>-s</tt> and <tt>-i</tt> options.</span></dd>
+<p> As in NTP subnets, NTP secure groups are configured as an acyclic tree rooted on the THs. The THs are at the lowest stratum of the secure group. They run the identity exchange with the TAs of the host groups. All group hosts construct an unbroken certificate trail from each host, possibly via intermediate hosts, and ending at a TH of that group. The TH verifies authenticity with the TA of a host group.</p>
+<p> While the certificate trail authenticates each host on the trail to the THs, it does not validate the time values themselves. Ultimately, this is determined by the NTP on-wire protocool.</p>
<div align="center"><img src="pic/flt9.gif" alt="gif">
<p>Figure 2. Identify Scheme</p>
</div>
-<p>As shown in Figure 2, an Autokey identity scheme involves a challenge-response exchange where a client generates a nonce and sends to the server. The server performs a mathematical operation involving a second nonce and the secret group key, and sends the result along with a hash to the client. The client performs a another mathematical operation and verifies the result with the hash.</p>
+<p>The identity exchange is run between a TA acting as a server and a TH acting as a client. As shown in Figure 2, an Autokey identity scheme involves a challenge-response exchange where a client generates a nonce and sends to the server. The server performs a mathematical operation involving a second nonce and the secret group key, and sends the result along with a hash to the client. The client performs a another mathematical operation and verifies the result with the hash.</p>
<p> Since each exchange involves two nonces, even after repeated observations of many exchanges, an intruder cannot learn the secret group key. It is this quality that allows the secret group key to persist long after the longest period of certificate validity. In the Schnorr (Identify Friend or Foe - IFF) scheme, the secret group key is not divulged to the clients, so they cannot conspire to prove identity to other hosts.</p>
<p>As described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page, there are five identity schemes, three of which - IFF, GQ and MV - require identity files specific to each scheme. There are two types of files for each scheme, an encrypted server keys file and a nonencrypted client keys file, also called the parameters file, which usually contains a subset of the keys file.</p>
-<p> Figure 2 shows how keys and parameters are distributed to servers and clients. Here, a TH constructs the encrypted keys file and the nonencrypted parameters file. Hosts with no dependent clients can retrieve client parameter files from an
- archive or web page. The <tt>ntp-keygen</tt> program can export parameter files using the <tt>-e</tt> option.
- Servers with dependent clients other than THs must retrieve copies of the server
+<p> Figure 2 shows how keys and parameters are distributed to servers and clients. Here, a TA constructs the encrypted keys file and the nonencrypted parameters file. Hosts with no dependent clients can retrieve client parameter files from an
+ archive or web page. The <tt>ntp-keygen</tt> program can export parameter files using the <tt>-e</tt> option. By convention, the file name is the name of the secure group and must match the <tt>ident</tt> command option and the <tt>ident</tt> option of the <tt>server</tt> command.</p>
+<p> When more than one TH Is involved, it is conventient to distribute copies of the keys file with different passwords. THs can retrieve copies of the server
keys file using secure means. The <tt>ntp-keygen</tt> program can export server keys files
using the <tt>-q</tt> option and chosen remote password. In either case the files are installed
and then renamed using the name given as the first line in the file, but without
- the filestamp.</p>
+ the filestamp. Unless the files are named according to the following conventions, it may be necessary to use symbolic links.</p>
+<p>In the current version of Autokey, it is not necessary to provide a name for the secure group. However, a name is required for previous Aurokwy versions. ONe of the TAs of the host group generatees the identify keys and parameters files and exports the keys file to all other TAs seving the secure group as described in the previous section. </p>
+<p>The string specified by the <tt>-i</tt> option of the <tt>ntp-keygen</tt> program is the name of the secure group. This name must match the <tt>ident</tt> option
+ of the <tt>crypto</tt> command of all TAs in the host group. The name is used in the identity keys and parameters file names, but has no effect on protocol opedrations. The file naming conventions are described on
+ the <a href="keygen.html">ntp-keygen</a> page.</p>
+<dl>
+ <dd><span class="style1">In the latest Autokey version, the host name and group name are independent of each other and the <tt>host</tt> option of the <tt>crypto</tt> command is deprecated. When compatibility with older versions is required, specify the same name for both the <tt>-s</tt> and <tt>-i</tt> options.</span></dd>
+</dl>
<p>Example</p>
<p>Returning to the example of Figure 1, Alice, Helen and Carol run TC, internally, as the environment is secure and without threat from external attack, in particular a middleman masquerade. However, TH X of Carol is vulnerable to masquerade on the links between X and C and between X and S. Therefor, both C and S are configured as Autokey servers with, for example, the IFF identity scheme, and X as a client of both of them. For this purpose, both C and S export their IFF parameter files to X as described above.</p>
+<dl>
+ <dd><span class="style1">In the latest Autokey version, the host name and group name are independent of each other and the <tt>host</tt> option of the <tt>crypto</tt> command is deprecated. When compatibility with older versions is required, specify the same name for both the <tt>-s</tt> and <tt>-i</tt> options.</span></dd>
+</dl>
<h4 id="config2">Configuration - Authentication Schemes</h4>
<p>Autokey has an intimidating number of options, most of which are not necessary in typical scenarios. However, the Trusted Certificate (TC) scheme is recommended for national NTP time services, such as those operated by NIST and USNO. Configuration for TC is very simple. For each server, e.g. <tt>time.nist.gov,</tt> as root:</p>
<p><tt># cd /usr/local/etc<br>
# driftfile /etc/ntp.drift</tt></p>
<p>It is possible to configure clients of server <tt>grundoon.udel.edu</tt> in the same way with the server line pointing to <tt>grundoon.udel.edu</tt>. Dependent clients authenticate to <tt>time.nistg.gov</tt> through <tt>grundoon.udel.edu</tt>.</p>
<p>In the above configuration examples, the default Autokey host name is the string returned by the Unix <tt>gethostname()</tt> library routine. However, this name has nothing to do with the DNS name of the host. The Autokey host name is used as the subject and issuer names on the certificate, as well as the default password for the encrypted keys files. The Autokey host name can be changed using the <tt>-s</tt> option of the <tt>ntp-keygen</tt> program. The default password can be changed using the <tt>-p</tt> option of the <tt>ntp-keygen</tt> program and the <tt>pw</tt> option of the <tt>crypto</tt> command.</p>
-<h4 ident="ident">Configuration - Identity Schemes</h4>
-<p> For the simplest identity scheme TC, the server generates host keys, trusted certificate and identity files using an <tt>ntp-keygen </tt> program commadn with options specified in this section, while the clients use the same command with no options. The server uses the <tt>crypto</tt> command in the comnfiguration file with options specified in this section, while the clients use the same command with no options. Additonia client options are specified in the <tt>server</tt> command for each association. </p>
-<p> It's best to start with a functioning TC configuation and add commands as necessary. For example, the CA generates an encrypted server keys file using the command</p>
-<p><tt>ntp-keygen -I -i <em>group</em></tt>,</p>
-<p> where <em><tt>group</tt></em> is the group name used by all hosts in the group. This and following commands can be combined in a single command. The nonencrypted client parameters can be exported using the command</p>
+<h4 id="ident">Configuration - Identity Schemes</h4>
+<p> For the simplest identity scheme TC, the server TA generates identity files using an <tt>ntp-keygen </tt> program commadn with options specified in this section, while the client TH uses the same command with no options. The TA uses the <tt>crypto</tt> command in the comnfiguration file with options specified in this section, while the TH uses the same command with no options. Additional TH options are specified in the <tt>server</tt> and <tt>ident</tt> command for each association. </p>
+<p> It's best to start with a functioning TC configuation and add commands as necessary. For example, the TA generates an encrypted server keys file using the command</p>
+<p><tt>ntp-keygen -I</tt>.</p>
+<p> Note the TA is not a trusted host, so does not have the <tt>-T</tt> option. The nonencrypted client parameters can be exported using the command</p>
<p><tt>ntp-keygen -e ><i>file</i></tt>,</p>
-<p>where the <tt>-e</tt> option redirects the client parameters to <em><tt>file</tt></em> via the standard output stream for a mail application or stored locally for later distribution. In a similar fashion the encrypted keys file can be exported using the command </p>
+<p>where the <tt>-e</tt> option redirects the client parameters to <em><tt>file</tt></em> via the standard output stream for a mail application or stored locally for later distribution to one or more THs. In a similar fashion the encrypted keys file can be exported using the command </p>
<p><tt>ntp-keygen -q <em>passw2</em> ><i>file</i></tt>,</p>
-<p>where <em><tt>passwd2</tt></em> is the read password for another host. In either case the file is installed under the name<tt> </tt>found in the first line of the file, but converted to lower case and without the filestamp</p>
+<p>where <em><tt>passwd2</tt></em> is the read password for another host. In the client case the file name is arbitrary as used in the server and ident commands. In the server case the file is installed under the name<tt> </tt>found in the first line of the file, but converted to lower case and without the filestamp</p>
<p>As in the TC scheme, the server includes a <tt>crypto</tt> command in the configuration file with the <tt>ident <em>group</em></tt> option. The crypto command in the client configuration file is unchanged, but the server command includes the <tt>ident <em>group</em></tt> option.</p>
<p>In special circumstances the Autokey message digest algorithm can be changed using the <tt>digest</tt> option of the <tt>crypto</tt> command. The digest algorithm is separate and distinct from the symmetric
key message digest algorithm. If compliance with FIPS 140-2 is required,
<p><img src="pic/alice23.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a></p>
<p>Alice holds the key.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->14-Dec-2010 5:00<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->22-Dec-2010 21:55<!-- #EndDate -->
</p>
<br clear="left">
<h4>Related Links</h4>
<dt><tt>-H</tt></dt>
<dd>Generate a new encrypted RSA public/private host key file.</dd>
<dt><tt>-i <i>group</i></tt></dt>
- <dd>Set the group name to <tt><i>group</i></tt>. This is used in the identity file names. It must match the group name specified in the <tt>ident</tt> option of the <tt>crypto</tt> configuration command.</dd>
+ <dd>Set the optional group name to <tt><i>group</i></tt>. This is used in the identity file names. If used, it must match the group name specified in the <tt>ident</tt> option of the <tt>crypto</tt> configuration command.</dd>
<dt><tt>-I</tt></dt>
<dd>Generate a new encrypted IFF key file for the Schnorr (IFF) identity scheme. This option is mutually exclusive with the <tt>-G</tt> and <tt>-V</tt> options.</dd>
<dt><tt>-l <i>days</i></tt></dt>
<img src="pic/wingdorothy.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>The Wizard of Oz</i>, L. Frank Baum</a>
<p>You need help from the monkeys.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->06-Sep-2010 18:50<!-- #EndDate -->
-UTC</p>
+ <!-- #BeginDate format:En2m -->21-Dec-2010 13:51<!-- #EndDate -->
+ UTC</p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
<h4 id="synop">Synopsis</h4>
<tt>ntpd [ -46aAbdDgLmnNqx ] [ -c <i>conffile</i> ] [ -f <i>driftfile</i> ] [ -i <i>jaildir</i> ] [ -k <i>keyfile</i> ] [ -l <i>logfile</i> ] [ -p <i>pidfile</i> ] [ -P <i>priority</i> ] [ -r <i>broadcastdelay</i> ] [ -s <i>statsdir</i> ] [ -t <i>key</i> ] [ -u <i>user</i>[:<i>group</i>] ] [ -U <i>interface_update_interval</i> ] [ -v <i>variable</i> ] [ -V <i>variable</i> ]</tt>
<h4 id="descr">Description</h4>
-<p>The <tt>ntpd</tt> program is an operating system daemon that synchronises the system clock to remote NTP time servers or local reference clocks. It is a complete implementation of NTP version 4 defined by RFC-5905, but also retains compatibley with version 3 defined by RFC-1305 and versions 1 and 2, defined by RFC-1059 and RFC-1119, respectively. The program can operate in any of several modes, including client/server, symmetric and broadcasrt modes, and with both symmetric-key and public key-cryptography</p>
+<p>The <tt>ntpd</tt> program is an operating system daemon that synchronizes the system clock to remote NTP time servers or local reference clocks. It is a complete implementation of NTP version 4 defined by RFC-5905, but also retains compatible with version 3 defined by RFC-1305 and versions 1 and 2, defined by RFC-1059 and RFC-1119, respectively. The program can operate in any of several modes, including client/server, symmetric and broadcast modes, and with both symmetric-key and public key-cryptography</p>
<p>The <tt>ntpd</tt> program ordinarily requires a configuration file described on this page. It contains configuration commands described on the pages listed above. However a client can discover remote servers and configure them automatically. This makes it possible to deploy a fleet of workstations without specifying configuration details specific to the local environment. Further details are on the </p>
-<p>The <tt>ntpd</tt> program normally operates continuously while adjusting the system time and frequency, but in some cases this might not be practical. With the <tt>-q</tt> option <tt>ntpd</tt> operates as in continous mode, but exits just after setting the clock for the first time. Most applications will probably want to specify the <tt>iburst</tt> option with the <tt>server</tt> command. With this option a volley of messages is exchanged to groom the data and set the clock in about ten seconds. If nothing is heard after a few minutes, the daemon times out and exits without setting the clock.</p>
+<p>The <tt>ntpd</tt> program normally operates continuously while adjusting the system time and frequency, but in some cases this might not be practical. With the <tt>-q</tt> option <tt>ntpd</tt> operates as in continuous mode, but exits just after setting the clock for the first time. Most applications will probably want to specify the <tt>iburst</tt> option with the <tt>server</tt> command. With this option a volley of messages is exchanged to groom the data and set the clock in about ten seconds. If nothing is heard after a few minutes, the daemon times out and exits without setting the clock.</p>
<h4 id="cmd">Command Line Options</h4>
<dl>
<dt><tt>-a</tt></dt>
<dt><tt>-b</tt></dt>
<dd>Enable the client to synchronize to broadcast servers.</dd>
<dt><tt>-c <i>conffile</i></tt></dt>
- <dd>Specify the name and path of the configuration file, default <tt>/etc/ntp.conf</tt>.</dd>
+ <dd>Specify the name and path of the configuration file. Without the option the default is <tt>/etc/ntp.conf</tt>.</dd>
<dt><tt>-d</tt></dt>
- <dd>Specify debugging mode. This option may occur more than once, with each occurrence indicating greater detail of display.</dd>
+ <dd> Disable switching into daemon mode, so <tt>ntpd</tt> stays attached to the starting terminal which will get all the debugging printout. Also, ^C will kill it. This option may occur more than once, with each occurrence indicating greater detail of display.</dd>
<dt><tt>-D <i>level</i></tt></dt>
- <dd>Specify debugging level directly.</dd>
+ <dd>Specify debugging level directly, with <tt>level</tt> corresponding to the numbe of <tt>-d</tt> options..</dd>
<dt><tt>-f <i>driftfile</i></tt></dt>
- <dd>Specify the name and path of the frequency file, default <tt>/etc/ntp.drift</tt>. This is the same operation as the <tt>driftfile <i>driftfile</i></tt> command.</dd>
+ <dd>Specify the name and path of the frequency file. This is the same operation as the <tt>driftfile</tt> command.</dd>
<dt><tt>-g</tt></dt>
<dd>Normally, <tt>ntpd</tt> exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the threshold is exceeded after that, <tt>ntpd</tt> will exit with a message to the system log. This option can be used with the <tt>-q</tt> and <tt>-x</tt> options. See the <tt>tinker</tt> command for other options.</dd>
<dt><tt>-i <i>jaildir</i></tt></dt>
<dt id="--novirtualips"><tt>-L</tt></dt>
<dd>Do not listen to virtual interfaces, defined as those with names containing a colon. This option is deprecated. Please consider using the configuration file <a href="miscopt.html#interface">interface</a> command, which is more versatile.</dd>
<dt><tt>-M</tt></dt>
- <dd>Raise scheduler precision to its maximum (1 msec) using timeBeginPeriod. (Windows only)</dd>
+ <dd>Raise scheduler precision to its maximum (1 ms) using timeBeginPeriod. (Windows only)</dd>
<dt><tt>-n</tt></dt>
<dd>Don't fork.</dd>
<dt><tt>-N</tt></dt>
<dt><tt>-u <i>user[:group]</i> </tt></dt>
<dd>Specify a user, and optionally a group, to switch to. This option is only available if the OS supports running the server without full root privileges. Currently, this option is supported under NetBSD (configure with <tt>--enable-clockctl</tt>) and Linux (configure with --<tt>enable-linuxcaps</tt>).</dd>
<dt><tt>-U <i>interface update interval</i></tt></dt>
- <dd>Number of seconds to wait between interface list scans to pick up new and delete network interface. Set to 0 to disable dynamic interface list updating. The default is to scan every 5 minutes.</dd>
- <dt><tt>-v <i>variable</i></tt></dt>
- <dt><tt>-V <i>variable</i></tt></dt>
+ <dd>Number of seconds to wait between interface list scans to pick up old and delete network interface. Set to 0 to disable dynamic interface list updating. The default is to scan every 5 minutes.</dd>
+ <dt><tt>-v <i>variable</i></tt><br>
+ <tt>-V <i>variable</i></tt></dt>
<dd>Add a system variable listed by default.</dd>
<dt><tt>-x</tt></dt>
<dd>Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold. This option sets the threshold to 600 s, which is well within the accuracy window to set the clock manually. Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment as much as 600 s will take almost 14 days to complete. This option can be used with the <tt>-g</tt> and <tt>-q</tt> options. See the <tt>tinker</tt> command for other options. Note: The kernel time discipline is disabled with this option.</dd>
<td width="30%">File</td>
<td width="30%">Default</td>
<td width="20%">Option</td>
- <td width="20%">Command</td>
+ <td width="20%">Option</td>
</tr>
<tr>
<td width="30%">configuration file</td>
<td width="30%"><tt>/etc/ntp.conf</tt></td>
<td width="20%"><tt>-c</tt></td>
- <td width="20%">none</td>
+ <td width="20%"><tt>conffile</tt></td>
</tr>
<tr>
<td width="30%">frequency file</td>
<img src="pic/bustardfly.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>A typical NTP monitoring packet</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->09-Oct-2010 20:03<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->21-Dec-2010 14:31<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>More Help</h4>
</dd>
<dt><tt>clockvar <i>assocID</i> [<i>name</i> [ = <i>value</i> [...]] [...]</tt><br>
<tt>cv <i>assocID</i> [<i>name</i> [ = <i>value</i> [...] ][...]</tt></dt>
- <dd>Display a list of <a href="#clock">clock variables</a> for those assocations supporting a reference clock.</dd>
+ <dd>Display a list of <a href="#clock">clock variables</a> for those associations supporting a reference clock.</dd>
<dt><tt>:config [...]</tt></dt>
<dd>Send the remainder of the command line, including whitespace, to the server as a run-time configuration command in the same format as the configuration file. This command is experimental until further notice and clarification. Authentication is of course required.</dd>
<dt><tt>config-from-file <i>filename</i></tt></dt>
<dt><tt>keyid</tt></dt>
<dd>Specify the key ID to use for write requests.</dd>
<dt><tt>lassociations</tt></dt>
- <dd>Perform the same function as the associations command, execept display mobilized and unmobilized associations.</dd>
+ <dd>Perform the same function as the associations command, except display mobilized and unmobilized associations.</dd>
<dt id="monstats"><tt>monstats</tt></dt>
<dd>Display monitor facility statistics.</dd>
<dt id="mrulist"><tt>mrulist [limited | kod | mincount=<i>count</i> | laddr=<i>localaddr</i> | sort=<i>sortorder</i> | resany=<i>hexmask</i> | resall=<i>hexmask</i>]</tt></dt>
</tr>
<tr>
<td><tt>offset</tt></td>
- <td>offset</td>
+ <td>offset of server relative to this host</td>
</tr>
<tr>
<td><tt>jitter</tt></td>
in the format YYYYMMDDTTTT, where YYYY is the year, MM the month
of year, DD the day of month and TTTT the time of day.</dd>
<dt id="saveconfig"><tt>saveconfig <i>filename</i></tt></dt>
- <dd>Write the current configuration, including any runtime modifications given with <tt>:config</tt> or <tt>config-from-file</tt>, to the ntpd host's file <i>filename</i>. This command will be rejected by the server unless <a href="miscopt.html#saveconfigdir">saveconfigdir</a> appears in the <tt>ntpd</tt> configuration file. <i>filename</i> can use strftime() format specifiers to substitute the current date and time, for example, <tt>saveconfig ntp-%Y%m%d-%H%M%S.conf</tt>. The filename used is stored in system variable <tt>savedconfig</tt>. Authentication is required.</dd>
+ <dd>Write the current configuration, including any runtime modifications given with <tt>:config</tt> or <tt>config-from-file</tt>, to the ntpd host's file <i>filename</i>. This command will be rejected by the server unless <a href="miscopt.html#saveconfigdir">saveconfigdir</a> appears in the <tt>ntpd</tt> configuration file. <i>filename</i> can use strftime() format specifies to substitute the current date and time, for example, <tt>saveconfig ntp-%Y%m%d-%H%M%S.conf</tt>. The filename used is stored in system variable <tt>savedconfig</tt>. Authentication is required.</dd>
<dt><tt>writevar <i>assocID</i> <i>name</i> = <i>value</i> [,...]</tt></dt>
<dd>Write the specified variables. If the <tt><i>assocID</i></tt> is zero, the variables are from the <a href="#system">system variables</a> name space, otherwise they are from the <a href="#peer">peer variables</a> name space. The <tt><i>assocID</i></tt> is required, as the same name can occur in both spaces.</dd>
<dt id="sysstats"><tt>sysstats</tt></dt>
</tr>
<tr>
<td><tt>offset</tt></td>
- <td>combined time offset</td>
+ <td>combined offset of server relative to this host</td>
</tr>
<tr>
<td><tt>sys_jitter</tt></td>
</tr>
<tr>
<td><tt>frequency</tt></td>
- <td>clock frequency offset (PPM)</td>
+ <td> frequency offset (PPM) relative to hardware clock</td>
</tr>
<tr>
<td><tt>clk_wander</tt></td>
</tr>
<tr>
<td><tt>host</tt></td>
- <td>Autokey host name</td>
+ <td>Autokey host name for this host</td>
</tr>
<tr>
- <td><tt>group</tt></td>
- <td>Autokey group name</td>
+ <td><tt>ident</tt></td>
+ <td>Autokey group name for this host</td>
</tr>
<tr>
<td><tt>flags</tt></td>
</tr>
</table>
<h4 id="peer">Peer Variables</h4>
-<p>The following peer variables apear in the <tt>rv</tt> billboard for each association. Not all variables are displayed in some configurations.</p>
+<p>The following peer variables appear in the <tt>rv</tt> billboard for each association. Not all variables are displayed in some configurations.</p>
<table width="100%" border="1" cellspacing="2" cellpadding="2">
<tr>
<td>Variable</td>
<td><tt>jitter</tt></td>
<td>filter jitter</td>
</tr>
+ <tr>
+ <td><tt>ident</tt></td>
+ <td>Autokey group name for this association</td>
+ </tr>
<tr>
<td><tt>bias</tt></td>
<td>unicast/broadcast bias</td>
<td>interleave delay (see <a href="xleave.html">NTP Interleaved Modes</a>)</td>
</tr>
</table>
-<p>The bias vaqriable is calculated when the first broadcast packet is received
+<p>The bias variable is calculated when the first broadcast packet is received
after the calibration volley. It represents the offset of the broadcast
subgraph relative to the unicast subgraph. The xleave variable appears
- only the interleaved symmetric and ingterleaved modes. It represents
- the internal queueing, buffering and transmission delays for the preceeding
+ only the interleaved symmetric and interleaved modes. It represents
+ the internal queuing, buffering and transmission delays for the preceding
packet.</p>
<p>When the NTPv4 daemon is compiled with the OpenSSL software library, additional peer variables are displayed, including the following:</p>
<table width="100%" border="1" cellspacing="2" cellpadding="2">
</tr>
<tr>
<td><tt>signature</tt></td>
- <td>OpenSSL digest/signature shceme</td>
+ <td>OpenSSL digest/signature scheme</td>
</tr>
<tr>
<td><tt>initsequence</tt></td>
</tr>
</table>
<h4 id="clock">Clock Variables</h4>
-<p>The following clock variables apear in the <tt>cv</tt> billboard for each association with a reference clock. Not all variables are displayed in some configurations.</p>
+<p>The following clock variables appear in the <tt>acv</tt> billboard for each association with a reference clock. Not all variables are displayed in some configurations.</p>
<table width="100%" border="1" cellspacing="2" cellpadding="2">
<tr>
<td>Variable</td>
<td>Description</td>
</tr>
<tr>
- <td><tt>associd</tt></td>
+ <td><tt>assoc id</tt></td>
<td>association ID</td>
</tr>
<tr>
<td>device description</td>
</tr>
<tr>
- <td><tt>timecode</tt></td>
- <td>ASCII timecode string (specific to device)</td>
+ <td><tt>time code</tt></td>
+ <td>ASCII time code string (specific to device)</td>
</tr>
<tr>
<td><tt>poll</tt></td>
<td>poll messages sent</td>
</tr>
<tr>
- <td><tt>noreply</tt></td>
+ <td><tt>no reply</tt></td>
<td>no reply</td>
</tr>
<tr>
- <td><tt>badformat</tt></td>
+ <td><tt>bad format</tt></td>
<td>bad format</td>
</tr>
<tr>
- <td><tt>baddata</tt></td>
+ <td><tt>bad data</tt></td>
<td>bad date or time</td>
</tr>
<tr>
<td>driver stratum</td>
</tr>
<tr>
- <td><tt>refid</tt></td>
+ <td><tt>re fid</tt></td>
<td>driver reference ID</td>
</tr>
<tr>
projects / thirdparty / ntp.git / commitdiff
