+(4.2.7p332) 2012/12/06 Released by Harlan Stenn <stenn@ntp.org>
* sntp documentation cleanup.
(4.2.7p331) 2012/12/03 Released by Harlan Stenn <stenn@ntp.org>
* [Bug 2114] Correctly calculate sntp's synch distance.
#
# EDIT THIS FILE WITH CAUTION (invoke-ntp.conf.texi)
#
-# It has been AutoGen-ed December 5, 2012 at 10:46:00 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 6, 2012 at 07:44:20 AM by AutoGen 5.16.2
# From the definitions ntp.conf.def
# and the template file agtexi-cmd.tpl
@end ignore
#
# EDIT THIS FILE WITH CAUTION (invoke-ntp.keys.texi)
#
-# It has been AutoGen-ed December 5, 2012 at 10:46:02 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 6, 2012 at 07:44:22 AM by AutoGen 5.16.2
# From the definitions ntp.keys.def
# and the template file agtexi-cmd.tpl
@end ignore
#
# EDIT THIS FILE WITH CAUTION (invoke-ntpd.texi)
#
-# It has been AutoGen-ed December 3, 2012 at 11:41:33 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 6, 2012 at 07:44:23 AM by AutoGen 5.16.2
# From the definitions ntpd-opts.def
# and the template file agtexi-cmd.tpl
@end ignore
@exampleindent 0
@example
-ntpd - NTP daemon program - Ver. 4.2.7p331
+ntpd - NTP daemon program - Ver. 4.2.7p332
USAGE: ntpd [ -<flag> [<val>] | --<name>[@{=| @}<val>] ]... \
[ <server1> ... <serverN> ]
Flg Arg Option-Name Description
-.TH ntp.conf 5man "05 Dec 2012" "4.2.7p331" "File Formats"
+.TH ntp.conf 5man "06 Dec 2012" "4.2.7p332" "File Formats"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp.man)
.\"
-.\" It has been AutoGen-ed December 5, 2012 at 10:46:03 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:07 AM by AutoGen 5.16.2
.\" From the definitions ntp.conf.def
.\" and the template file agman-cmd.tpl
.\"
All arguments must be options.
.PP
.SH DESCRIPTION
-The
-.B
-configuration file is read at initial startup by the
-.Xr ntpd 1ntpdmdoc
-daemon in order to specify the synchronization sources,
-modes and other related information.
-Usually, it is installed in the
-.Pa /etc
-directory,
-but could be installed elsewhere
-(see the daemon's
-c
-command line option).
-.PP
-The file format is similar to other
-.Ux
-configuration files.
-Comments begin with a
-.Ql #
-character and extend to the end of the line;
-blank lines are ignored.
-Configuration commands consist of an initial keyword
-followed by a list of arguments,
-some of which may be optional, separated by whitespace.
-Commands may not be continued over multiple lines.
-Arguments may be host names,
-host addresses written in numeric, dotted-quad form,
-integers, floating point numbers (when specifying times in seconds)
-and text strings.
-.PP
-The rest of this page describes the configuration and control options.
-The
-.Qq Notes on Configuring NTP and Setting up a NTP Subnet
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-contains an extended discussion of these options.
-In addition to the discussion of general
-.Sx Configuration Options ,
-there are sections describing the following supported functionality
-and the options used to control it:
-.in +4
-.ti -4
-\fB*\fP
-
-.Sx Authentication Support
-.ti -4
-\fB*\fP
-
-.Sx Monitoring Support
-.ti -4
-\fB*\fP
-
-.Sx Access Control Support
-.ti -4
-\fB*\fP
-
-.Sx Automatic NTP Configuration Options
-.ti -4
-\fB*\fP
-
-.Sx Reference Clock Support
-.ti -4
-\fB*\fP
-
-.Sx Miscellaneous Options
-.in -4
-.PP
-Following these is a section describing
-.Sx Miscellaneous Options .
-While there is a rich set of options available,
-the only required option is one or more
-.Ic pool ,
-.Ic server ,
-.Ic peer ,
-.Ic broadcast
-or
-.Ic manycastclient
-commands.
-.SH Configuration Support
-Following is a description of the configuration commands in
-NTPv4.
-These commands have the same basic functions as in NTPv3 and
-in some cases new functions and new arguments.
-There are two
-classes of commands, configuration commands that configure a
-persistent association with a remote server or peer or reference
-clock, and auxiliary commands that specify environmental variables
-that control various related operations.
-.SS Configuration Commands
-The various modes are determined by the command keyword and the
-type of the required IP address.
-Addresses are classed by type as
-(s) a remote server or peer (IPv4 class A, B and C), (b) the
-broadcast address of a local interface, (m) a multicast address (IPv4
-class D), or (r) a reference clock address (127.127.x.x).
-Note that
-only those options applicable to each command are listed below.
-Use
-of options not listed may not be caught as an error, but may result
-in some weird and even destructive behavior.
-.PP
-If the Basic Socket Interface Extensions for IPv6 (RFC-2553)
-is detected, support for the IPv6 address family is generated
-in addition to the default support of the IPv4 address family.
-In a few cases, including the reslist billboard generated
-by ntpdc, IPv6 addresses are automatically generated.
-IPv6 addresses can be identified by the presence of colons
-.Dq \&:
-in the address field.
-IPv6 addresses can be used almost everywhere where
-IPv4 addresses can be used,
-with the exception of reference clock addresses,
-which are always IPv4.
-.PP
-Note that in contexts where a host name is expected, a
-4
-qualifier preceding
-the host name forces DNS resolution to the IPv4 namespace,
-while a
-6
-qualifier forces DNS resolution to the IPv6 namespace.
-See IPv6 references for the
-equivalent classes for that address family.
-.TP
-.BR Xo Ic pool Ar address
-[ "\fIburst\fR" ]
-[ "\fIiburst\fR" ]
-[ "\fIversion\fR" "\fIversion\fR" ]
-[ "\fIprefer\fR" ]
-[ "\fIminpoll\fR" "\fIminpoll\fR" ]
-[ "\fImaxpoll\fR" "\fImaxpoll\fR" ]
-.Xc
-.TP
-.BR Xo Ic server Ar address
-[ "\fIkey\fR" "\fIkey\fR" \&| "\fIautokey\fR" ]
-[ "\fIburst\fR" ]
-[ "\fIiburst\fR" ]
-[ "\fIversion\fR" "\fIversion\fR" ]
-[ "\fIprefer\fR" ]
-[ "\fIminpoll\fR" "\fIminpoll\fR" ]
-[ "\fImaxpoll\fR" "\fImaxpoll\fR" ]
-.Xc
-.TP
-.BR Xo Ic peer Ar address
-[ "\fIkey\fR" "\fIkey\fR" \&| "\fIautokey\fR" ]
-[ "\fIversion\fR" "\fIversion\fR" ]
-[ "\fIprefer\fR" ]
-[ "\fIminpoll\fR" "\fIminpoll\fR" ]
-[ "\fImaxpoll\fR" "\fImaxpoll\fR" ]
-.Xc
-.TP
-.BR Xo Ic broadcast Ar address
-[ "\fIkey\fR" "\fIkey\fR" \&| "\fIautokey\fR" ]
-[ "\fIversion\fR" "\fIversion\fR" ]
-[ "\fIprefer\fR" ]
-[ "\fIminpoll\fR" "\fIminpoll\fR" ]
-[ "\fIttl\fR" "\fIttl\fR" ]
-.Xc
-.TP
-.BR Xo Ic manycastclient Ar address
-[ "\fIkey\fR" "\fIkey\fR" \&| "\fIautokey\fR" ]
-[ "\fIversion\fR" "\fIversion\fR" ]
-[ "\fIprefer\fR" ]
-[ "\fIminpoll\fR" "\fIminpoll\fR" ]
-[ "\fImaxpoll\fR" "\fImaxpoll\fR" ]
-[ "\fIttl\fR" "\fIttl\fR" ]
-.Xc
-.PP
-These five commands specify the time server name or address to
-be used and the mode in which to operate.
-The
-\fIaddress\fR
-can be
-either a DNS name or an IP address in dotted-quad notation.
-Additional information on association behavior can be found in the
-.Qq Association Management
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.TP
-.BR Ic pool
-For type s addresses, this command mobilizes a persistent
-client mode association with a number of remote servers.
-In this mode the local clock can synchronized to the
-remote server, but the remote server can never be synchronized to
-the local clock.
-.TP
-.BR Ic server
-For type s and r addresses, this command mobilizes a persistent
-client mode association with the specified remote server or local
-radio clock.
-In this mode the local clock can synchronized to the
-remote server, but the remote server can never be synchronized to
-the local clock.
-This command should
-.I not
-be used for type
-b or m addresses.
-.TP
-.BR Ic peer
-For type s addresses (only), this command mobilizes a
-persistent symmetric-active mode association with the specified
-remote peer.
-In this mode the local clock can be synchronized to
-the remote peer or the remote peer can be synchronized to the local
-clock.
-This is useful in a network of servers where, depending on
-various failure scenarios, either the local or remote peer may be
-the better source of time.
-This command should NOT be used for type
-b, m or r addresses.
-.TP
-.BR Ic broadcast
-For type b and m addresses (only), this
-command mobilizes a persistent broadcast mode association.
-Multiple
-commands can be used to specify multiple local broadcast interfaces
-(subnets) and/or multiple multicast groups.
-Note that local
-broadcast messages go only to the interface associated with the
-subnet specified, but multicast messages go to all interfaces.
-In broadcast mode the local server sends periodic broadcast
-messages to a client population at the
-\fIaddress\fR
-specified, which is usually the broadcast address on (one of) the
-local network(s) or a multicast address assigned to NTP.
-The IANA
-has assigned the multicast group address IPv4 224.0.1.1 and
-IPv6 ff05::101 (site local) exclusively to
-NTP, but other nonconflicting addresses can be used to contain the
-messages within administrative boundaries.
-Ordinarily, this
-specification applies only to the local server operating as a
-sender; for operation as a broadcast client, see the
-.Ic broadcastclient
-or
-.Ic multicastclient
-commands
-below.
-.TP
-.BR Ic manycastclient
-For type m addresses (only), this command mobilizes a
-manycast client mode association for the multicast address
-specified.
-In this case a specific address must be supplied which
-matches the address used on the
-.Ic manycastserver
-command for
-the designated manycast servers.
-The NTP multicast address
-224.0.1.1 assigned by the IANA should NOT be used, unless specific
-means are taken to avoid spraying large areas of the Internet with
-these messages and causing a possibly massive implosion of replies
-at the sender.
-The
-.Ic manycastserver
-command specifies that the local server
-is to operate in client mode with the remote servers that are
-discovered as the result of broadcast/multicast messages.
-The
-client broadcasts a request message to the group address associated
-with the specified
-\fIaddress\fR
-and specifically enabled
-servers respond to these messages.
-The client selects the servers
-providing the best time and continues as with the
-.Ic server
-command.
-The remaining servers are discarded as if never
-heard.
-.PP
-Options:
-.TP
-.BR Cm autokey
-All packets sent to and received from the server or peer are to
-include authentication fields encrypted using the autokey scheme
-described in
-.Sx Authentication Options .
-.TP
-.BR Cm burst
-when the server is reachable, send a burst of eight packets
-instead of the usual one.
-The packet spacing is normally 2 s;
-however, the spacing between the first and second packets
-can be changed with the calldelay command to allow
-additional time for a modem or ISDN call to complete.
-This is designed to improve timekeeping quality
-with the
-.Ic server
-command and s addresses.
-.TP
-.BR Cm iburst
-When the server is unreachable, send a burst of eight packets
-instead of the usual one.
-The packet spacing is normally 2 s;
-however, the spacing between the first two packets can be
-changed with the calldelay command to allow
-additional time for a modem or ISDN call to complete.
-This is designed to speed the initial synchronization
-acquisition with the
-.Ic server
-command and s addresses and when
-.Xr ntpd 1ntpdmdoc
-is started with the
-q
-option.
-.TP
-.BR Cm key Ar key
-All packets sent to and received from the server or peer are to
-include authentication fields encrypted using the specified
-\fIkey\fR
-identifier with values from 1 to 65534, inclusive.
-The
-default is to include no encryption field.
-.TP
-.BR Cm minpoll Ar minpoll
-.TP
-.BR Cm maxpoll Ar maxpoll
-These options specify the minimum and maximum poll intervals
-for NTP messages, as a power of 2 in seconds
-The maximum poll
-interval defaults to 10 (1,024 s), but can be increased by the
-.Cm maxpoll
-option to an upper limit of 17 (36.4 h).
-The
-minimum poll interval defaults to 6 (64 s), but can be decreased by
-the
-.Cm minpoll
-option to a lower limit of 4 (16 s).
-.TP
-.BR Cm noselect
-Marks the server as unused, except for display purposes.
-The server is discarded by the selection algroithm.
-.TP
-.BR Cm prefer
-Marks the server as preferred.
-All other things being equal,
-this host will be chosen for synchronization among a set of
-correctly operating hosts.
-See the
-.Qq Mitigation Rules and the prefer Keyword
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-for further information.
-.TP
-.BR Cm ttl Ar ttl
-This option is used only with broadcast server and manycast
-client modes.
-It specifies the time-to-live
-\fIttl\fR
-to
-use on broadcast server and multicast server and the maximum
-\fIttl\fR
-for the expanding ring search with manycast
-client packets.
-Selection of the proper value, which defaults to
-127, is something of a black art and should be coordinated with the
-network administrator.
-.TP
-.BR Cm version Ar version
-Specifies the version number to be used for outgoing NTP
-packets.
-Versions 1-4 are the choices, with version 4 the
-default.
-.SS Auxiliary Commands
-.TP
-.BR Ic broadcastclient
-This command enables reception of broadcast server messages to
-any local interface (type b) address.
-Upon receiving a message for
-the first time, the broadcast client measures the nominal server
-propagation delay using a brief client/server exchange with the
-server, then enters the broadcast client mode, in which it
-synchronizes to succeeding broadcast messages.
-Note that, in order
-to avoid accidental or malicious disruption in this mode, both the
-server and client should operate using symmetric-key or public-key
-authentication as described in
-.Sx Authentication Options .
-.TP
-.BR Ic manycastserver Ar address ...
-This command enables reception of manycast client messages to
-the multicast group address(es) (type m) specified.
-At least one
-address is required, but the NTP multicast address 224.0.1.1
-assigned by the IANA should NOT be used, unless specific means are
-taken to limit the span of the reply and avoid a possibly massive
-implosion at the original sender.
-Note that, in order to avoid
-accidental or malicious disruption in this mode, both the server
-and client should operate using symmetric-key or public-key
-authentication as described in
-.Sx Authentication Options .
-.TP
-.BR Ic multicastclient Ar address ...
-This command enables reception of multicast server messages to
-the multicast group address(es) (type m) specified.
-Upon receiving
-a message for the first time, the multicast client measures the
-nominal server propagation delay using a brief client/server
-exchange with the server, then enters the broadcast client mode, in
-which it synchronizes to succeeding multicast messages.
-Note that,
-in order to avoid accidental or malicious disruption in this mode,
-both the server and client should operate using symmetric-key or
-public-key authentication as described in
-.Sx Authentication Options .
-.SH Authentication Support
-Authentication support allows the NTP client to verify that the
-server is in fact known and trusted and not an intruder intending
-accidentally or on purpose to masquerade as that server.
-The NTPv3
-specification RFC-1305 defines a scheme which provides
-cryptographic authentication of received NTP packets.
-Originally,
-this was done using the Data Encryption Standard (DES) algorithm
-operating in Cipher Block Chaining (CBC) mode, commonly called
-DES-CBC.
-Subsequently, this was replaced by the RSA Message Digest
-5 (MD5) algorithm using a private key, commonly called keyed-MD5.
-Either algorithm computes a message digest, or one-way hash, which
-can be used to verify the server has the correct private key and
-key identifier.
-.PP
-NTPv4 retains the NTPv3 scheme, properly described as symmetric key
-cryptography and, in addition, provides a new Autokey scheme
-based on public key cryptography.
-Public key cryptography is generally considered more secure
-than symmetric key cryptography, since the security is based
-on a private value which is generated by each server and
-never revealed.
-With Autokey all key distribution and
-management functions involve only public values, which
-considerably simplifies key distribution and storage.
-Public key management is based on X.509 certificates,
-which can be provided by commercial services or
-produced by utility programs in the OpenSSL software library
-or the NTPv4 distribution.
-.PP
-While the algorithms for symmetric key cryptography are
-included in the NTPv4 distribution, public key cryptography
-requires the OpenSSL software library to be installed
-before building the NTP distribution.
-Directions for doing that
-are on the Building and Installing the Distribution page.
-.PP
-Authentication is configured separately for each association
-using the
-.Cm key
-or
-.Cm autokey
-subcommand on the
-.Ic peer ,
-.Ic server ,
-.Ic broadcast
-and
-.Ic manycastclient
-configuration commands as described in
-.Sx Configuration Options
-page.
-The authentication
-options described below specify the locations of the key files,
-if other than default, which symmetric keys are trusted
-and the interval between various operations, if other than default.
-.PP
-Authentication is always enabled,
-although ineffective if not configured as
-described below.
-If a NTP packet arrives
-including a message authentication
-code (MAC), it is accepted only if it
-passes all cryptographic checks.
-The
-checks require correct key ID, key value
-and message digest.
-If the packet has
-been modified in any way or replayed
-by an intruder, it will fail one or more
-of these checks and be discarded.
-Furthermore, the Autokey scheme requires a
-preliminary protocol exchange to obtain
-the server certificate, verify its
-credentials and initialize the protocol
-.PP
-The
-.Cm auth
-flag controls whether new associations or
-remote configuration commands require cryptographic authentication.
-This flag can be set or reset by the
-.Ic enable
-and
-.Ic disable
-commands and also by remote
-configuration commands sent by a
-.Xr ntpdc 1ntpdcmdoc
-program running in
-another machine.
-If this flag is enabled, which is the default
-case, new broadcast client and symmetric passive associations and
-remote configuration commands must be cryptographically
-authenticated using either symmetric key or public key cryptography.
-If this
-flag is disabled, these operations are effective
-even if not cryptographic
-authenticated.
-It should be understood
-that operating with the
-.Ic auth
-flag disabled invites a significant vulnerability
-where a rogue hacker can
-masquerade as a falseticker and seriously
-disrupt system timekeeping.
-It is
-important to note that this flag has no purpose
-other than to allow or disallow
-a new association in response to new broadcast
-and symmetric active messages
-and remote configuration commands and, in particular,
-the flag has no effect on
-the authentication process itself.
-.PP
-An attractive alternative where multicast support is available
-is manycast mode, in which clients periodically troll
-for servers as described in the
-.Sx Automatic NTP Configuration Options
-page.
-Either symmetric key or public key
-cryptographic authentication can be used in this mode.
-The principle advantage
-of manycast mode is that potential servers need not be
-configured in advance,
-since the client finds them during regular operation,
-and the configuration
-files for all clients can be identical.
-.PP
-The security model and protocol schemes for
-both symmetric key and public key
-cryptography are summarized below;
-further details are in the briefings, papers
-and reports at the NTP project page linked from
-.Li http://www.ntp.org/ .
-.SS Symmetric-Key Cryptography
-The original RFC-1305 specification allows any one of possibly
-65,534 keys, each distinguished by a 32-bit key identifier, to
-authenticate an association.
-The servers and clients involved must
-agree on the key and key identifier to
-authenticate NTP packets.
-Keys and
-related information are specified in a key
-file, usually called
-.Pa ntp.keys ,
-which must be distributed and stored using
-secure means beyond the scope of the NTP protocol itself.
-Besides the keys used
-for ordinary NTP associations,
-additional keys can be used as passwords for the
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-utility programs.
-.PP
-When
-.Xr ntpd 1ntpdmdoc
-is first started, it reads the key file specified in the
-.Ic keys
-configuration command and installs the keys
-in the key cache.
-However,
-individual keys must be activated with the
-.Ic trusted
-command before use.
-This
-allows, for instance, the installation of possibly
-several batches of keys and
-then activating or deactivating each batch
-remotely using
-.Xr ntpdc 1ntpdcmdoc .
-This also provides a revocation capability that can be used
-if a key becomes compromised.
-The
-.Ic requestkey
-command selects the key used as the password for the
-.Xr ntpdc 1ntpdcmdoc
-utility, while the
-.Ic controlkey
-command selects the key used as the password for the
-.Xr ntpq 1ntpqmdoc
-utility.
-.SS Public Key Cryptography
-NTPv4 supports the original NTPv3 symmetric key scheme
-described in RFC-1305 and in addition the Autokey protocol,
-which is based on public key cryptography.
-The Autokey Version 2 protocol described on the Autokey Protocol
-page verifies packet integrity using MD5 message digests
-and verifies the source with digital signatures and any of several
-digest/signature schemes.
-Optional identity schemes described on the Identity Schemes
-page and based on cryptographic challenge/response algorithms
-are also available.
-Using all of these schemes provides strong security against
-replay with or without modification, spoofing, masquerade
-and most forms of clogging attacks.
-.\" .Pp
-.\" The cryptographic means necessary for all Autokey operations
-.\" is provided by the OpenSSL software library.
-.\" This library is available from http://www.openssl.org/
-.\" and can be installed using the procedures outlined
-.\" in the Building and Installing the Distribution page.
-.\" Once installed,
-.\" the configure and build
-.\" process automatically detects the library and links
-.\" the library routines required.
-.PP
-The Autokey protocol has several modes of operation
-corresponding to the various NTP modes supported.
-Most modes use a special cookie which can be
-computed independently by the client and server,
-but encrypted in transmission.
-All modes use in addition a variant of the S-KEY scheme,
-in which a pseudo-random key list is generated and used
-in reverse order.
-These schemes are described along with an executive summary,
-current status, briefing slides and reading list on the
-.Sx Autonomous Authentication
-page.
-.PP
-The specific cryptographic environment used by Autokey servers
-and clients is determined by a set of files
-and soft links generated by the
-.Xr ntp-keygen 1ntpkeygenmdoc
-program.
-This includes a required host key file,
-required certificate file and optional sign key file,
-leapsecond file and identity scheme files.
-The
-digest/signature scheme is specified in the X.509 certificate
-along with the matching sign key.
-There are several schemes
-available in the OpenSSL software library, each identified
-by a specific string such as
-.Cm md5WithRSAEncryption ,
-which stands for the MD5 message digest with RSA
-encryption scheme.
-The current NTP distribution supports
-all the schemes in the OpenSSL library, including
-those based on RSA and DSA digital signatures.
-.PP
-NTP secure groups can be used to define cryptographic compartments
-and security hierarchies.
-It is important that every host
-in the group be able to construct a certificate trail to one
-or more trusted hosts in the same group.
-Each group
-host runs the Autokey protocol to obtain the certificates
-for all hosts along the trail to one or more trusted hosts.
-This requires the configuration file in all hosts to be
-engineered so that, even under anticipated failure conditions,
-the NTP subnet will form such that every group host can find
-a trail to at least one trusted host.
-.SS Naming and Addressing
-It is important to note that Autokey does not use DNS to
-resolve addresses, since DNS can't be completely trusted
-until the name servers have synchronized clocks.
-The cryptographic name used by Autokey to bind the host identity
-credentials and cryptographic values must be independent
-of interface, network and any other naming convention.
-The name appears in the host certificate in either or both
-the subject and issuer fields, so protection against
-DNS compromise is essential.
-.PP
-By convention, the name of an Autokey host is the name returned
-by the Unix
-.Xr gethostname 2
-system call or equivalent in other systems.
-By the system design
-model, there are no provisions to allow alternate names or aliases.
-However, this is not to say that DNS aliases, different names
-for each interface, etc., are constrained in any way.
-.PP
-It is also important to note that Autokey verifies authenticity
-using the host name, network address and public keys,
-all of which are bound together by the protocol specifically
-to deflect masquerade attacks.
-For this reason Autokey
-includes the source and destinatino IP addresses in message digest
-computations and so the same addresses must be available
-at both the server and client.
-For this reason operation
-with network address translation schemes is not possible.
-This reflects the intended robust security model where government
-and corporate NTP servers are operated outside firewall perimeters.
-.SS Operation
-A specific combination of authentication scheme (none,
-symmetric key, public key) and identity scheme is called
-a cryptotype, although not all combinations are compatible.
-There may be management configurations where the clients,
-servers and peers may not all support the same cryptotypes.
-A secure NTPv4 subnet can be configured in many ways while
-keeping in mind the principles explained above and
-in this section.
-Note however that some cryptotype
-combinations may successfully interoperate with each other,
-but may not represent good security practice.
-.PP
-The cryptotype of an association is determined at the time
-of mobilization, either at configuration time or some time
-later when a message of appropriate cryptotype arrives.
-When mobilized by a
-.Ic server
-or
-.Ic peer
-configuration command and no
-.Ic key
-or
-.Ic autokey
-subcommands are present, the association is not
-authenticated; if the
-.Ic key
-subcommand is present, the association is authenticated
-using the symmetric key ID specified; if the
-.Ic autokey
-subcommand is present, the association is authenticated
-using Autokey.
-.PP
-When multiple identity schemes are supported in the Autokey
-protocol, the first message exchange determines which one is used.
-The client request message contains bits corresponding
-to which schemes it has available.
-The server response message
-contains bits corresponding to which schemes it has available.
-Both server and client match the received bits with their own
-and select a common scheme.
-.PP
-Following the principle that time is a public value,
-a server responds to any client packet that matches
-its cryptotype capabilities.
-Thus, a server receiving
-an unauthenticated packet will respond with an unauthenticated
-packet, while the same server receiving a packet of a cryptotype
-it supports will respond with packets of that cryptotype.
-However, unconfigured broadcast or manycast client
-associations or symmetric passive associations will not be
-mobilized unless the server supports a cryptotype compatible
-with the first packet received.
-By default, unauthenticated associations will not be mobilized
-unless overridden in a decidedly dangerous way.
-.PP
-Some examples may help to reduce confusion.
-Client Alice has no specific cryptotype selected.
-Server Bob has both a symmetric key file and minimal Autokey files.
-Alice's unauthenticated messages arrive at Bob, who replies with
-unauthenticated messages.
-Cathy has a copy of Bob's symmetric
-key file and has selected key ID 4 in messages to Bob.
-Bob verifies the message with his key ID 4.
-If it's the
-same key and the message is verified, Bob sends Cathy a reply
-authenticated with that key.
-If verification fails,
-Bob sends Cathy a thing called a crypto-NAK, which tells her
-something broke.
-She can see the evidence using the ntpq program.
-.PP
-Denise has rolled her own host key and certificate.
-She also uses one of the identity schemes as Bob.
-She sends the first Autokey message to Bob and they
-both dance the protocol authentication and identity steps.
-If all comes out okay, Denise and Bob continue as described above.
-.PP
-It should be clear from the above that Bob can support
-all the girls at the same time, as long as he has compatible
-authentication and identity credentials.
-Now, Bob can act just like the girls in his own choice of servers;
-he can run multiple configured associations with multiple different
-servers (or the same server, although that might not be useful).
-But, wise security policy might preclude some cryptotype
-combinations; for instance, running an identity scheme
-with one server and no authentication with another might not be wise.
-.SS Key Management
-The cryptographic values used by the Autokey protocol are
-incorporated as a set of files generated by the
-.Xr ntp-keygen 1ntpkeygenmdoc
-utility program, including symmetric key, host key and
-public certificate files, as well as sign key, identity parameters
-and leapseconds files.
-Alternatively, host and sign keys and
-certificate files can be generated by the OpenSSL utilities
-and certificates can be imported from public certificate
-authorities.
-Note that symmetric keys are necessary for the
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-utility programs.
-The remaining files are necessary only for the
-Autokey protocol.
-.PP
-Certificates imported from OpenSSL or public certificate
-authorities have certian limitations.
-The certificate should be in ASN.1 syntax, X.509 Version 3
-format and encoded in PEM, which is the same format
-used by OpenSSL.
-The overall length of the certificate encoded
-in ASN.1 must not exceed 1024 bytes.
-The subject distinguished
-name field (CN) is the fully qualified name of the host
-on which it is used; the remaining subject fields are ignored.
-The certificate extension fields must not contain either
-a subject key identifier or a issuer key identifier field;
-however, an extended key usage field for a trusted host must
-contain the value
-.Cm trustRoot ; .
-Other extension fields are ignored.
-.SS Authentication Commands
-.TP
-.BR Ic autokey Op Ar logsec
-Specifies the interval between regenerations of the session key
-list used with the Autokey protocol.
-Note that the size of the key
-list for each association depends on this interval and the current
-poll interval.
-The default value is 12 (4096 s or about 1.1 hours).
-For poll intervals above the specified interval, a session key list
-with a single entry will be regenerated for every message
-sent.
-.TP
-.BR Ic controlkey Ar key
-Specifies the key identifier to use with the
-.Xr ntpq 1ntpqmdoc
-utility, which uses the standard
-protocol defined in RFC-1305.
-The
-\fIkey\fR
-argument is
-the key identifier for a trusted key, where the value can be in the
-range 1 to 65,534, inclusive.
-.TP
-.BR Xo Ic crypto
-[ "\fIcert\fR" "\fIfile\fR" ]
-[ "\fIleap\fR" "\fIfile\fR" ]
-[ "\fIrandfile\fR" "\fIfile\fR" ]
-[ "\fIhost\fR" "\fIfile\fR" ]
-[ "\fIsign\fR" "\fIfile\fR" ]
-[ "\fIgq\fR" "\fIfile\fR" ]
-[ "\fIgqpar\fR" "\fIfile\fR" ]
-[ "\fIiffpar\fR" "\fIfile\fR" ]
-[ "\fImvpar\fR" "\fIfile\fR" ]
-[ "\fIpw\fR" "\fIpassword\fR" ]
-.Xc
-This command requires the OpenSSL library.
-It activates public key
-cryptography, selects the message digest and signature
-encryption scheme and loads the required private and public
-values described above.
-If one or more files are left unspecified,
-the default names are used as described above.
-Unless the complete path and name of the file are specified, the
-location of a file is relative to the keys directory specified
-in the
-.Ic keysdir
-command or default
-.Pa /usr/local/etc .
-Following are the subcommands:
-.in +4
-.ti -4
-.IR Cm cert Ar file
-Specifies the location of the required host public certificate file.
-This overrides the link
-.Pa ntpkey_cert_ Ns Ar hostname
-in the keys directory.
-.ti -4
-.IR Cm gqpar Ar file
-Specifies the location of the optional GQ parameters file.
-This
-overrides the link
-.Pa ntpkey_gq_ Ns Ar hostname
-in the keys directory.
-.ti -4
-.IR Cm host Ar file
-Specifies the location of the required host key file.
-This overrides
-the link
-.Pa ntpkey_key_ Ns Ar hostname
-in the keys directory.
-.ti -4
-.IR Cm iffpar Ar file
-Specifies the location of the optional IFF parameters file.This
-overrides the link
-.Pa ntpkey_iff_ Ns Ar hostname
-in the keys directory.
-.ti -4
-.IR Cm leap Ar file
-Specifies the location of the optional leapsecond file.
-This overrides the link
-.Pa ntpkey_leap
-in the keys directory.
-.ti -4
-.IR Cm mvpar Ar file
-Specifies the location of the optional MV parameters file.
-This
-overrides the link
-.Pa ntpkey_mv_ Ns Ar hostname
-in the keys directory.
-.ti -4
-.IR Cm pw Ar password
-Specifies the password to decrypt files containing private keys and
-identity parameters.
-This is required only if these files have been
-encrypted.
-.ti -4
-.IR Cm randfile Ar file
-Specifies the location of the random seed file used by the OpenSSL
-library.
-The defaults are described in the main text above.
-.ti -4
-.IR Cm sign Ar file
-Specifies the location of the optional sign key file.
-This overrides
-the link
-.Pa ntpkey_sign_ Ns Ar hostname
-in the keys directory.
-If this file is
-not found, the host key is also the sign key.
-.in -4
-.TP
-.BR Ic keys Ar keyfile
-Specifies the complete path and location of the MD5 key file
-containing the keys and key identifiers used by
-.Xr ntpd 1ntpdmdoc ,
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-when operating with symmetric key cryptography.
-This is the same operation as the
-k
-command line option.
-.TP
-.BR Ic keysdir Ar path
-This command specifies the default directory path for
-cryptographic keys, parameters and certificates.
-The default is
-.Pa /usr/local/etc/ .
-.TP
-.BR Ic requestkey Ar key
-Specifies the key identifier to use with the
-.Xr ntpdc 1ntpdcmdoc
-utility program, which uses a
-proprietary protocol specific to this implementation of
-.Xr ntpd 1ntpdmdoc .
-The
-\fIkey\fR
-argument is a key identifier
-for the trusted key, where the value can be in the range 1 to
-65,534, inclusive.
-.TP
-.BR Ic revoke Ar logsec
-Specifies the interval between re-randomization of certain
-cryptographic values used by the Autokey scheme, as a power of 2 in
-seconds.
-These values need to be updated frequently in order to
-deflect brute-force attacks on the algorithms of the scheme;
-however, updating some values is a relatively expensive operation.
-The default interval is 16 (65,536 s or about 18 hours).
-For poll
-intervals above the specified interval, the values will be updated
-for every message sent.
-.TP
-.BR Ic trustedkey Ar key ...
-Specifies the key identifiers which are trusted for the
-purposes of authenticating peers with symmetric key cryptography,
-as well as keys used by the
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-programs.
-The authentication procedures require that both the local
-and remote servers share the same key and key identifier for this
-purpose, although different keys can be used with different
-servers.
-The
-\fIkey\fR
-arguments are 32-bit unsigned
-integers with values from 1 to 65,534.
-.SS Error Codes
-The following error codes are reported via the NTP control
-and monitoring protocol trap mechanism.
-.TP
-.BR 101
-.Pq bad field format or length
-The packet has invalid version, length or format.
-.TP
-.BR 102
-.Pq bad timestamp
-The packet timestamp is the same or older than the most recent received.
-This could be due to a replay or a server clock time step.
-.TP
-.BR 103
-.Pq bad filestamp
-The packet filestamp is the same or older than the most recent received.
-This could be due to a replay or a key file generation error.
-.TP
-.BR 104
-.Pq bad or missing public key
-The public key is missing, has incorrect format or is an unsupported type.
-.TP
-.BR 105
-.Pq unsupported digest type
-The server requires an unsupported digest/signature scheme.
-.TP
-.BR 106
-.Pq mismatched digest types
-Not used.
-.TP
-.BR 107
-.Pq bad signature length
-The signature length does not match the current public key.
-.TP
-.BR 108
-.Pq signature not verified
-The message fails the signature check.
-It could be bogus or signed by a
-different private key.
-.TP
-.BR 109
-.Pq certificate not verified
-The certificate is invalid or signed with the wrong key.
-.TP
-.BR 110
-.Pq certificate not verified
-The certificate is not yet valid or has expired or the signature could not
-be verified.
-.TP
-.BR 111
-.Pq bad or missing cookie
-The cookie is missing, corrupted or bogus.
-.TP
-.BR 112
-.Pq bad or missing leapseconds table
-The leapseconds table is missing, corrupted or bogus.
-.TP
-.BR 113
-.Pq bad or missing certificate
-The certificate is missing, corrupted or bogus.
-.TP
-.BR 114
-.Pq bad or missing identity
-The identity key is missing, corrupt or bogus.
-.SH Monitoring Support
-.Xr ntpd 1ntpdmdoc
-includes a comprehensive monitoring facility suitable
-for continuous, long term recording of server and client
-timekeeping performance.
-See the
-.Ic statistics
-command below
-for a listing and example of each type of statistics currently
-supported.
-Statistic files are managed using file generation sets
-and scripts in the
-.Pa ./scripts
-directory of this distribution.
-Using
-these facilities and
-.Ux
-.Xr cron 8
-jobs, the data can be
-automatically summarized and archived for retrospective analysis.
-.SS Monitoring Commands
-.TP
-.BR Ic statistics Ar name ...
-Enables writing of statistics records.
-Currently, four kinds of
-\fIname\fR
-statistics are supported.
-.in +4
-.ti -4
-.IR Cm clockstats
-Enables recording of clock driver statistics information.
-Each update
-received from a clock driver appends a line of the following form to
-the file generation set named
-.Cm clockstats :
-.br
-.in +4
-.nf
-49213 525.624 127.127.4.1 93 226 00:08:29.606 D
-.in -4
-.fi
-.PP
-The first two fields show the date (Modified Julian Day) and time
-(seconds and fraction past UTC midnight).
-The next field shows the
-clock address in dotted-quad notation.
-The final field shows the last
-timecode received from the clock in decoded ASCII format, where
-meaningful.
-In some clock drivers a good deal of additional information
-can be gathered and displayed as well.
-See information specific to each
-clock for further details.
-.ti -4
-.IR Cm cryptostats
-This option requires the OpenSSL cryptographic software library.
-It
-enables recording of cryptographic public key protocol information.
-Each message received by the protocol module appends a line of the
-following form to the file generation set named
-.Cm cryptostats :
-.br
-.in +4
-.nf
-49213 525.624 127.127.4.1 message
-.in -4
-.fi
-.PP
-The first two fields show the date (Modified Julian Day) and time
-(seconds and fraction past UTC midnight).
-The next field shows the peer
-address in dotted-quad notation, The final message field includes the
-message type and certain ancillary information.
-See the
-.Sx Authentication Options
-section for further information.
-.ti -4
-.IR Cm loopstats
-Enables recording of loop filter statistics information.
-Each
-update of the local clock outputs a line of the following form to
-the file generation set named
-.Cm loopstats :
-.br
-.in +4
-.nf
-50935 75440.031 0.000006019 13.778190 0.000351733 0.0133806
-.in -4
-.fi
-.PP
-The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight).
-The next five fields
-show time offset (seconds), frequency offset (parts per million -
-PPM), RMS jitter (seconds), Allan deviation (PPM) and clock
-discipline time constant.
-.ti -4
-.IR Cm peerstats
-Enables recording of peer statistics information.
-This includes
-statistics records of all peers of a NTP server and of special
-signals, where present and configured.
-Each valid update appends a
-line of the following form to the current element of a file
-generation set named
-.Cm peerstats :
-.br
-.in +4
-.nf
-48773 10847.650 127.127.4.1 9714 -0.001605376 0.000000000 0.001424877 0.000958674
-.in -4
-.fi
-.PP
-The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight).
-The next two fields
-show the peer address in dotted-quad notation and status,
-respectively.
-The status field is encoded in hex in the format
-described in Appendix A of the NTP specification RFC 1305.
-The final four fields show the offset,
-delay, dispersion and RMS jitter, all in seconds.
-.ti -4
-.IR Cm rawstats
-Enables recording of raw-timestamp statistics information.
-This
-includes statistics records of all peers of a NTP server and of
-special signals, where present and configured.
-Each NTP message
-received from a peer or clock driver appends a line of the
-following form to the file generation set named
-.Cm rawstats :
-.br
-.in +4
-.nf
-50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 3102453281.58622800031 02453332.540806000 3102453332.541458000
-.in -4
-.fi
-.PP
-The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight).
-The next two fields
-show the remote peer or clock address followed by the local address
-in dotted-quad notation.
-The final four fields show the originate,
-receive, transmit and final NTP timestamps in order.
-The timestamp
-values are as received and before processing by the various data
-smoothing and mitigation algorithms.
-.ti -4
-.IR Cm sysstats
-Enables recording of ntpd statistics counters on a periodic basis.
-Each
-hour a line of the following form is appended to the file generation
-set named
-.Cm sysstats :
-.br
-.in +4
-.nf
-50928 2132.543 36000 81965 0 9546 56 71793 512 540 10 147
-.in -4
-.fi
-.PP
-The first two fields show the date (Modified Julian Day) and time
-(seconds and fraction past UTC midnight).
-The remaining ten fields show
-the statistics counter values accumulated since the last generated
-line.
-.in +4
-.ti -4
-.IR Time since restart Cm 36000
-Time in hours since the system was last rebooted.
-.ti -4
-.IR Packets received Cm 81965
-Total number of packets received.
-.ti -4
-.IR Packets processed Cm 0
-Number of packets received in response to previous packets sent
-.ti -4
-.IR Current version Cm 9546
-Number of packets matching the current NTP version.
-.ti -4
-.IR Previous version Cm 56
-Number of packets matching the previous NTP version.
-.ti -4
-.IR Bad version Cm 71793
-Number of packets matching neither NTP version.
-.ti -4
-.IR Access denied Cm 512
-Number of packets denied access for any reason.
-.ti -4
-.IR Bad length or format Cm 540
-Number of packets with invalid length, format or port number.
-.ti -4
-.IR Bad authentication Cm 10
-Number of packets not verified as authentic.
-.ti -4
-.IR Rate exceeded Cm 147
-Number of packets discarded due to rate limitation.
-.in -4
-.ti -4
-.IR Cm statsdir Ar directory_path
-Indicates the full path of a directory where statistics files
-should be created (see below).
-This keyword allows
-the (otherwise constant)
-.Cm filegen
-filename prefix to be modified for file generation sets, which
-is useful for handling statistics logs.
-.ti -4
-.IR Cm filegen Ar name Xo
-[ "\fIfile\fR" "\fIfilename\fR" ]
-[ "\fItype\fR" "\fItypename\fR" ]
-[ "\fIlink\fR" | nolink ]
-[ "\fIenable\fR" | disable ]
-.Xc
-Configures setting of generation file set name.
-Generation
-file sets provide a means for handling files that are
-continuously growing during the lifetime of a server.
-Server statistics are a typical example for such files.
-Generation file sets provide access to a set of files used
-to store the actual data.
-At any time at most one element
-of the set is being written to.
-The type given specifies
-when and how data will be directed to a new element of the set.
-This way, information stored in elements of a file set
-that are currently unused are available for administrational
-operations without the risk of disturbing the operation of ntpd.
-(Most important: they can be removed to free space for new data
-produced.)
-.PP
-Note that this command can be sent from the
-.Xr ntpdc 1ntpdcmdoc
-program running at a remote location.
-.in +4
-.ti -4
-.IR Cm name
-This is the type of the statistics records, as shown in the
-.Cm statistics
-command.
-.ti -4
-.IR Cm file Ar filename
-This is the file name for the statistics records.
-Filenames of set
-members are built from three concatenated elements
-\fICm prefix ,\fR
-\fICm filename\fR
-and
-\fICm suffix :\fR
-.in +4
-.ti -4
-.IR Cm prefix
-This is a constant filename path.
-It is not subject to
-modifications via the
-\fIfilegen\fR
-option.
-It is defined by the
-server, usually specified as a compile-time constant.
-It may,
-however, be configurable for individual file generation sets
-via other commands.
-For example, the prefix used with
-\fIloopstats\fR
-and
-\fIpeerstats\fR
-generation can be configured using the
-\fIstatsdir\fR
-option explained above.
-.ti -4
-.IR Cm filename
-This string is directly concatenated to the prefix mentioned
-above (no intervening
-.Ql / ) .
-This can be modified using
-the file argument to the
-\fIfilegen\fR
-statement.
-No
-.Pa ..
-elements are
-allowed in this component to prevent filenames referring to
-parts outside the filesystem hierarchy denoted by
-\fIprefix .\fR
-.ti -4
-.IR Cm suffix
-This part is reflects individual elements of a file set.
-It is
-generated according to the type of a file set.
-.in -4
-.ti -4
-.IR Cm type Ar typename
-A file generation set is characterized by its type.
-The following
-types are supported:
-.in +4
-.ti -4
-.IR Cm none
-The file set is actually a single plain file.
-.ti -4
-.IR Cm pid
-One element of file set is used per incarnation of a ntpd
-server.
-This type does not perform any changes to file set
-members during runtime, however it provides an easy way of
-separating files belonging to different
-.Xr ntpd 1ntpdmdoc
-server incarnations.
-The set member filename is built by appending a
-.Ql \&.
-to concatenated
-\fIprefix\fR
-and
-\fIfilename\fR
-strings, and
-appending the decimal representation of the process ID of the
-.Xr ntpd 1ntpdmdoc
-server process.
-.ti -4
-.IR Cm day
-One file generation set element is created per day.
-A day is
-defined as the period between 00:00 and 24:00 UTC.
-The file set
-member suffix consists of a
-.Ql \&.
-and a day specification in
-the form
-.Cm YYYYMMdd .
-.Cm YYYY
-is a 4-digit year number (e.g., 1992).
-.Cm MM
-is a two digit month number.
-.Cm dd
-is a two digit day number.
-Thus, all information written at 10 December 1992 would end up
-in a file named
-\fIprefix\fR
-\fIfilename Ns .19921210 .\fR
-.ti -4
-.IR Cm week
-Any file set member contains data related to a certain week of
-a year.
-The term week is defined by computing day-of-year
-modulo 7.
-Elements of such a file generation set are
-distinguished by appending the following suffix to the file set
-filename base: A dot, a 4-digit year number, the letter
-.Cm W ,
-and a 2-digit week number.
-For example, information from January,
-10th 1992 would end up in a file with suffix
-.No . Ns Ar 1992W1 .
-.ti -4
-.IR Cm month
-One generation file set element is generated per month.
-The
-file name suffix consists of a dot, a 4-digit year number, and
-a 2-digit month.
-.ti -4
-.IR Cm year
-One generation file element is generated per year.
-The filename
-suffix consists of a dot and a 4 digit year number.
-.ti -4
-.IR Cm age
-This type of file generation sets changes to a new element of
-the file set every 24 hours of server operation.
-The filename
-suffix consists of a dot, the letter
-.Cm a ,
-and an 8-digit number.
-This number is taken to be the number of seconds the server is
-running at the start of the corresponding 24-hour period.
-Information is only written to a file generation by specifying
-.Cm enable ;
-output is prevented by specifying
-.Cm disable .
-.in -4
-.ti -4
-.IR Cm link | nolink
-It is convenient to be able to access the current element of a file
-generation set by a fixed name.
-This feature is enabled by
-specifying
-.Cm link
-and disabled using
-.Cm nolink .
-If link is specified, a
-hard link from the current file set element to a file without
-suffix is created.
-When there is already a file with this name and
-the number of links of this file is one, it is renamed appending a
-dot, the letter
-.Cm C ,
-and the pid of the ntpd server process.
-When the
-number of links is greater than one, the file is unlinked.
-This
-allows the current file to be accessed by a constant name.
-.ti -4
-.IR Cm enable \&| Cm disable
-Enables or disables the recording function.
-.in -4
-.in -4
-.SH Access Control Support
-The
-.Xr ntpd 1ntpdmdoc
-daemon implements a general purpose address/mask based restriction
-list.
-The list contains address/match entries sorted first
-by increasing address values and and then by increasing mask values.
-A match occurs when the bitwise AND of the mask and the packet
-source address is equal to the bitwise AND of the mask and
-address in the list.
-The list is searched in order with the
-last match found defining the restriction flags associated
-with the entry.
-Additional information and examples can be found in the
-.Qq Notes on Configuring NTP and Setting up a NTP Subnet
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.PP
-The restriction facility was implemented in conformance
-with the access policies for the original NSFnet backbone
-time servers.
-Later the facility was expanded to deflect
-cryptographic and clogging attacks.
-While this facility may
-be useful for keeping unwanted or broken or malicious clients
-from congesting innocent servers, it should not be considered
-an alternative to the NTP authentication facilities.
-Source address based restrictions are easily circumvented
-by a determined cracker.
-.PP
-Clients can be denied service because they are explicitly
-included in the restrict list created by the restrict command
-or implicitly as the result of cryptographic or rate limit
-violations.
-Cryptographic violations include certificate
-or identity verification failure; rate limit violations generally
-result from defective NTP implementations that send packets
-at abusive rates.
-Some violations cause denied service
-only for the offending packet, others cause denied service
-for a timed period and others cause the denied service for
-an indefinate period.
-When a client or network is denied access
-for an indefinate period, the only way at present to remove
-the restrictions is by restarting the server.
-.SS The Kiss-of-Death Packet
-Ordinarily, packets denied service are simply dropped with no
-further action except incrementing statistics counters.
-Sometimes a
-more proactive response is needed, such as a server message that
-explicitly requests the client to stop sending and leave a message
-for the system operator.
-A special packet format has been created
-for this purpose called the "kiss-of-death" (KoD) packet.
-KoD packets have the leap bits set unsynchronized and stratum set
-to zero and the reference identifier field set to a four-byte
-ASCII code.
-If the
-.Cm noserve
-or
-.Cm notrust
-flag of the matching restrict list entry is set,
-the code is "DENY"; if the
-.Cm limited
-flag is set and the rate limit
-is exceeded, the code is "RATE".
-Finally, if a cryptographic violation occurs, the code is "CRYP".
-.PP
-A client receiving a KoD performs a set of sanity checks to
-minimize security exposure, then updates the stratum and
-reference identifier peer variables, sets the access
-denied (TEST4) bit in the peer flash variable and sends
-a message to the log.
-As long as the TEST4 bit is set,
-the client will send no further packets to the server.
-The only way at present to recover from this condition is
-to restart the protocol at both the client and server.
-This
-happens automatically at the client when the association times out.
-It will happen at the server only if the server operator cooperates.
-.SS Access Control Commands
-.TP
-.BR Xo Ic discard
-[ "\fIaverage\fR" "\fIavg\fR" ]
-[ "\fIminimum\fR" "\fImin\fR" ]
-[ "\fImonitor\fR" "\fIprob\fR" ]
-.Xc
-Set the parameters of the
-.Cm limited
-facility which protects the server from
-client abuse.
-The
-.Cm average
-subcommand specifies the minimum average packet
-spacing, while the
-.Cm minimum
-subcommand specifies the minimum packet spacing.
-Packets that violate these minima are discarded
-and a kiss-o'-death packet returned if enabled.
-The default
-minimum average and minimum are 5 and 2, respectively.
-The monitor subcommand specifies the probability of discard
-for packets that overflow the rate-control window.
-.TP
-.BR Xo Ic restrict address
-[ "\fImask\fR" "\fImask\fR" ]
-[ "\fIflag\fR" ... ]
-.Xc
-The
-\fIaddress\fR
-argument expressed in
-dotted-quad form is the address of a host or network.
-Alternatively, the
-\fIaddress\fR
-argument can be a valid host DNS name.
-The
-\fImask\fR
-argument expressed in dotted-quad form defaults to
-.Cm 255.255.255.255 ,
-meaning that the
-\fIaddress\fR
-is treated as the address of an individual host.
-A default entry (address
-.Cm 0.0.0.0 ,
-mask
-.Cm 0.0.0.0 )
-is always included and is always the first entry in the list.
-Note that text string
-.Cm default ,
-with no mask option, may
-be used to indicate the default entry.
-In the current implementation,
-.Cm flag
-always
-restricts access, i.e., an entry with no flags indicates that free
-access to the server is to be given.
-The flags are not orthogonal,
-in that more restrictive flags will often make less restrictive
-ones redundant.
-The flags can generally be classed into two
-categories, those which restrict time service and those which
-restrict informational queries and attempts to do run-time
-reconfiguration of the server.
-One or more of the following flags
-may be specified:
-.in +4
-.ti -4
-.IR Cm ignore
-Deny packets of all kinds, including
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-queries.
-.ti -4
-.IR Cm kod
-If this flag is set when an access violation occurs, a kiss-o'-death
-(KoD) packet is sent.
-KoD packets are rate limited to no more than one
-per second.
-If another KoD packet occurs within one second after the
-last one, the packet is dropped.
-.ti -4
-.IR Cm limited
-Deny service if the packet spacing violates the lower limits specified
-in the discard command.
-A history of clients is kept using the
-monitoring capability of
-.Xr ntpd 1ntpdmdoc .
-Thus, monitoring is always active as
-long as there is a restriction entry with the
-.Cm limited
-flag.
-.ti -4
-.IR Cm lowpriotrap
-Declare traps set by matching hosts to be low priority.
-The
-number of traps a server can maintain is limited (the current limit
-is 3).
-Traps are usually assigned on a first come, first served
-basis, with later trap requestors being denied service.
-This flag
-modifies the assignment algorithm by allowing low priority traps to
-be overridden by later requests for normal priority traps.
-.ti -4
-.IR Cm nomodify
-Deny
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-queries which attempt to modify the state of the
-server (i.e., run time reconfiguration).
-Queries which return
-information are permitted.
-.ti -4
-.IR Cm noquery
-Deny
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-queries.
-Time service is not affected.
-.ti -4
-.IR Cm nopeer
-Deny packets which would result in mobilizing a new association.
-This
-includes broadcast and symmetric active packets when a configured
-association does not exist.
-.ti -4
-.IR Cm noserve
-Deny all packets except
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-queries.
-.ti -4
-.IR Cm notrap
-Decline to provide mode 6 control message trap service to matching
-hosts.
-The trap service is a subsystem of the ntpdq control message
-protocol which is intended for use by remote event logging programs.
-.ti -4
-.IR Cm notrust
-Deny service unless the packet is cryptographically authenticated.
-.ti -4
-.IR Cm ntpport
-This is actually a match algorithm modifier, rather than a
-restriction flag.
-Its presence causes the restriction entry to be
-matched only if the source port in the packet is the standard NTP
-UDP port (123).
-Both
-.Cm ntpport
-and
-.Cm non-ntpport
-may
-be specified.
-The
-.Cm ntpport
-is considered more specific and
-is sorted later in the list.
-.ti -4
-.IR Cm version
-Deny packets that do not match the current NTP version.
-.in -4
-.PP
-Default restriction list entries with the flags ignore, interface,
-ntpport, for each of the local host's interface addresses are
-inserted into the table at startup to prevent the server
-from attempting to synchronize to its own time.
-A default entry is also always present, though if it is
-otherwise unconfigured; no flags are associated
-with the default entry (i.e., everything besides your own
-NTP server is unrestricted).
-.SH Automatic NTP Configuration Options
-.SS Manycasting
-Manycasting is a automatic discovery and configuration paradigm
-new to NTPv4.
-It is intended as a means for a multicast client
-to troll the nearby network neighborhood to find cooperating
-manycast servers, validate them using cryptographic means
-and evaluate their time values with respect to other servers
-that might be lurking in the vicinity.
-The intended result is that each manycast client mobilizes
-client associations with some number of the "best"
-of the nearby manycast servers, yet automatically reconfigures
-to sustain this number of servers should one or another fail.
-.PP
-Note that the manycasting paradigm does not coincide
-with the anycast paradigm described in RFC-1546,
-which is designed to find a single server from a clique
-of servers providing the same service.
-The manycast paradigm is designed to find a plurality
-of redundant servers satisfying defined optimality criteria.
-.PP
-Manycasting can be used with either symmetric key
-or public key cryptography.
-The public key infrastructure (PKI)
-offers the best protection against compromised keys
-and is generally considered stronger, at least with relatively
-large key sizes.
-It is implemented using the Autokey protocol and
-the OpenSSL cryptographic library available from
-.Li http://www.openssl.org/ .
-The library can also be used with other NTPv4 modes
-as well and is highly recommended, especially for broadcast modes.
-.PP
-A persistent manycast client association is configured
-using the manycastclient command, which is similar to the
-server command but with a multicast (IPv4 class
-.Cm D
-or IPv6 prefix
-.Cm FF )
-group address.
-The IANA has designated IPv4 address 224.1.1.1
-and IPv6 address FF05::101 (site local) for NTP.
-When more servers are needed, it broadcasts manycast
-client messages to this address at the minimum feasible rate
-and minimum feasible time-to-live (TTL) hops, depending
-on how many servers have already been found.
-There can be as many manycast client associations
-as different group address, each one serving as a template
-for a future ephemeral unicast client/server association.
-.PP
-Manycast servers configured with the
-.Ic manycastserver
-command listen on the specified group address for manycast
-client messages.
-Note the distinction between manycast client,
-which actively broadcasts messages, and manycast server,
-which passively responds to them.
-If a manycast server is
-in scope of the current TTL and is itself synchronized
-to a valid source and operating at a stratum level equal
-to or lower than the manycast client, it replies to the
-manycast client message with an ordinary unicast server message.
-.PP
-The manycast client receiving this message mobilizes
-an ephemeral client/server association according to the
-matching manycast client template, but only if cryptographically
-authenticated and the server stratum is less than or equal
-to the client stratum.
-Authentication is explicitly required
-and either symmetric key or public key (Autokey) can be used.
-Then, the client polls the server at its unicast address
-in burst mode in order to reliably set the host clock
-and validate the source.
-This normally results
-in a volley of eight client/server at 2-s intervals
-during which both the synchronization and cryptographic
-protocols run concurrently.
-Following the volley,
-the client runs the NTP intersection and clustering
-algorithms, which act to discard all but the "best"
-associations according to stratum and synchronization
-distance.
-The surviving associations then continue
-in ordinary client/server mode.
-.PP
-The manycast client polling strategy is designed to reduce
-as much as possible the volume of manycast client messages
-and the effects of implosion due to near-simultaneous
-arrival of manycast server messages.
-The strategy is determined by the
-.Ic manycastclient ,
-.Ic tos
-and
-.Ic ttl
-configuration commands.
-The manycast poll interval is
-normally eight times the system poll interval,
-which starts out at the
-.Cm minpoll
-value specified in the
-.Ic manycastclient ,
-command and, under normal circumstances, increments to the
-.Cm maxpolll
-value specified in this command.
-Initially, the TTL is
-set at the minimum hops specified by the ttl command.
-At each retransmission the TTL is increased until reaching
-the maximum hops specified by this command or a sufficient
-number client associations have been found.
-Further retransmissions use the same TTL.
-.PP
-The quality and reliability of the suite of associations
-discovered by the manycast client is determined by the NTP
-mitigation algorithms and the
-.Cm minclock
-and
-.Cm minsane
-values specified in the
-.Ic tos
-configuration command.
-At least
-.Cm minsane
-candidate servers must be available and the mitigation
-algorithms produce at least
-.Cm minclock
-survivors in order to synchronize the clock.
-Byzantine agreement principles require at least four
-candidates in order to correctly discard a single falseticker.
-For legacy purposes,
-.Cm minsane
-defaults to 1 and
-.Cm minclock
-defaults to 3.
-For manycast service
-.Cm minsane
-should be explicitly set to 4, assuming at least that
-number of servers are available.
-.PP
-If at least
-.Cm minclock
-servers are found, the manycast poll interval is immediately
-set to eight times
-.Cm maxpoll .
-If less than
-.Cm minclock
-servers are found when the TTL has reached the maximum hops,
-the manycast poll interval is doubled.
-For each transmission
-after that, the poll interval is doubled again until
-reaching the maximum of eight times
-.Cm maxpoll .
-Further transmissions use the same poll interval and
-TTL values.
-Note that while all this is going on,
-each client/server association found is operating normally
-it the system poll interval.
-.PP
-Administratively scoped multicast boundaries are normally
-specified by the network router configuration and,
-in the case of IPv6, the link/site scope prefix.
-By default, the increment for TTL hops is 32 starting
-from 31; however, the
-.Ic ttl
-configuration command can be
-used to modify the values to match the scope rules.
-.PP
-It is often useful to narrow the range of acceptable
-servers which can be found by manycast client associations.
-Because manycast servers respond only when the client
-stratum is equal to or greater than the server stratum,
-primary (stratum 1) servers fill find only primary servers
-in TTL range, which is probably the most common objective.
-However, unless configured otherwise, all manycast clients
-in TTL range will eventually find all primary servers
-in TTL range, which is probably not the most common
-objective in large networks.
-The
-.Ic tos
-command can be used to modify this behavior.
-Servers with stratum below
-.Cm floor
-or above
-.Cm ceiling
-specified in the
-.Ic tos
-command are strongly discouraged during the selection
-process; however, these servers may be temporally
-accepted if the number of servers within TTL range is
-less than
-.Cm minclock .
-.PP
-The above actions occur for each manycast client message,
-which repeats at the designated poll interval.
-However, once the ephemeral client association is mobilized,
-subsequent manycast server replies are discarded,
-since that would result in a duplicate association.
-If during a poll interval the number of client associations
-falls below
-.Cm minclock ,
-all manycast client prototype associations are reset
-to the initial poll interval and TTL hops and operation
-resumes from the beginning.
-It is important to avoid
-frequent manycast client messages, since each one requires
-all manycast servers in TTL range to respond.
-The result could well be an implosion, either minor or major,
-depending on the number of servers in range.
-The recommended value for
-.Cm maxpoll
-is 12 (4,096 s).
-.PP
-It is possible and frequently useful to configure a host
-as both manycast client and manycast server.
-A number of hosts configured this way and sharing a common
-group address will automatically organize themselves
-in an optimum configuration based on stratum and
-synchronization distance.
-For example, consider an NTP
-subnet of two primary servers and a hundred or more
-dependent clients.
-With two exceptions, all servers
-and clients have identical configuration files including both
-.Ic multicastclient
-and
-.Ic multicastserver
-commands using, for instance, multicast group address
-239.1.1.1.
-The only exception is that each primary server
-configuration file must include commands for the primary
-reference source such as a GPS receiver.
-.PP
-The remaining configuration files for all secondary
-servers and clients have the same contents, except for the
-.Ic tos
-command, which is specific for each stratum level.
-For stratum 1 and stratum 2 servers, that command is
-not necessary.
-For stratum 3 and above servers the
-.Cm floor
-value is set to the intended stratum number.
-Thus, all stratum 3 configuration files are identical,
-all stratum 4 files are identical and so forth.
-.PP
-Once operations have stabilized in this scenario,
-the primary servers will find the primary reference source
-and each other, since they both operate at the same
-stratum (1), but not with any secondary server or client,
-since these operate at a higher stratum.
-The secondary
-servers will find the servers at the same stratum level.
-If one of the primary servers loses its GPS receiver,
-it will continue to operate as a client and other clients
-will time out the corresponding association and
-re-associate accordingly.
-.PP
-Some administrators prefer to avoid running
-.Xr ntpd 1ntpdmdoc
-continuously and run either
-.Xr ntpdate 8
-or
-.Xr ntpd 1ntpdmdoc
-q
-as a cron job.
-In either case the servers must be
-configured in advance and the program fails if none are
-available when the cron job runs.
-A really slick
-application of manycast is with
-.Xr ntpd 1ntpdmdoc
-q .
-The program wakes up, scans the local landscape looking
-for the usual suspects, selects the best from among
-the rascals, sets the clock and then departs.
-Servers do not have to be configured in advance and
-all clients throughout the network can have the same
-configuration file.
-.SS Manycast Interactions with Autokey
-Each time a manycast client sends a client mode packet
-to a multicast group address, all manycast servers
-in scope generate a reply including the host name
-and status word.
-The manycast clients then run
-the Autokey protocol, which collects and verifies
-all certificates involved.
-Following the burst interval
-all but three survivors are cast off,
-but the certificates remain in the local cache.
-It often happens that several complete signing trails
-from the client to the primary servers are collected in this way.
-.PP
-About once an hour or less often if the poll interval
-exceeds this, the client regenerates the Autokey key list.
-This is in general transparent in client/server mode.
-However, about once per day the server private value
-used to generate cookies is refreshed along with all
-manycast client associations.
-In this case all
-cryptographic values including certificates is refreshed.
-If a new certificate has been generated since
-the last refresh epoch, it will automatically revoke
-all prior certificates that happen to be in the
-certificate cache.
-At the same time, the manycast
-scheme starts all over from the beginning and
-the expanding ring shrinks to the minimum and increments
-from there while collecting all servers in scope.
-.SS Manycast Options
-.TP
-.BR Xo Ic tos
-.Oo
-.Cm ceiling Ar ceiling |
-.Cm cohort { 0 | 1 } |
-.Cm floor Ar floor |
-.Cm minclock Ar minclock |
-.Cm minsane Ar minsane
-.Oc
-.Xc
-This command affects the clock selection and clustering
-algorithms.
-It can be used to select the quality and
-quantity of peers used to synchronize the system clock
-and is most useful in manycast mode.
-The variables operate
-as follows:
-.in +4
-.ti -4
-.IR Cm ceiling Ar ceiling
-Peers with strata above
-.Cm ceiling
-will be discarded if there are at least
-.Cm minclock
-peers remaining.
-This value defaults to 15, but can be changed
-to any number from 1 to 15.
-.ti -4
-.IR Cm cohort Bro 0 | 1 Brc
-This is a binary flag which enables (0) or disables (1)
-manycast server replies to manycast clients with the same
-stratum level.
-This is useful to reduce implosions where
-large numbers of clients with the same stratum level
-are present.
-The default is to enable these replies.
-.ti -4
-.IR Cm floor Ar floor
-Peers with strata below
-.Cm floor
-will be discarded if there are at least
-.Cm minclock
-peers remaining.
-This value defaults to 1, but can be changed
-to any number from 1 to 15.
-.ti -4
-.IR Cm minclock Ar minclock
-The clustering algorithm repeatedly casts out outlyer
-associations until no more than
-.Cm minclock
-associations remain.
-This value defaults to 3,
-but can be changed to any number from 1 to the number of
-configured sources.
-.ti -4
-.IR Cm minsane Ar minsane
-This is the minimum number of candidates available
-to the clock selection algorithm in order to produce
-one or more truechimers for the clustering algorithm.
-If fewer than this number are available, the clock is
-undisciplined and allowed to run free.
-The default is 1
-for legacy purposes.
-However, according to principles of
-Byzantine agreement,
-.Cm minsane
-should be at least 4 in order to detect and discard
-a single falseticker.
-.in -4
-.TP
-.BR Cm ttl Ar hop ...
-This command specifies a list of TTL values in increasing
-order, up to 8 values can be specified.
-In manycast mode these values are used in turn
-in an expanding-ring search.
-The default is eight
-multiples of 32 starting at 31.
-.SH Reference Clock Support
-The NTP Version 4 daemon supports some three dozen different radio,
-satellite and modem reference clocks plus a special pseudo-clock
-used for backup or when no other clock source is available.
-Detailed descriptions of individual device drivers and options can
-be found in the
-.Qq Reference Clock Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-Additional information can be found in the pages linked
-there, including the
-.Qq Debugging Hints for Reference Clock Drivers
-and
-.Qq How To Write a Reference Clock Driver
-pages
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-In addition, support for a PPS
-signal is available as described in the
-.Qq Pulse-per-second (PPS) Signal Interfacing
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-Many
-drivers support special line discipline/streams modules which can
-significantly improve the accuracy using the driver.
-These are
-described in the
-.Qq Line Disciplines and Streams Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.PP
-A reference clock will generally (though not always) be a radio
-timecode receiver which is synchronized to a source of standard
-time such as the services offered by the NRC in Canada and NIST and
-USNO in the US.
-The interface between the computer and the timecode
-receiver is device dependent, but is usually a serial port.
-A
-device driver specific to each reference clock must be selected and
-compiled in the distribution; however, most common radio, satellite
-and modem clocks are included by default.
-Note that an attempt to
-configure a reference clock when the driver has not been compiled
-or the hardware port has not been appropriately configured results
-in a scalding remark to the system log file, but is otherwise non
-hazardous.
-.PP
-For the purposes of configuration,
-.Xr ntpd 1ntpdmdoc
-treats
-reference clocks in a manner analogous to normal NTP peers as much
-as possible.
-Reference clocks are identified by a syntactically
-correct but invalid IP address, in order to distinguish them from
-normal NTP peers.
-Reference clock addresses are of the form
-.Sm off
-.Li 127.127. Ar t . Ar u ,
-.Sm on
-where
-\fIt\fR
-is an integer
-denoting the clock type and
-\fIu\fR
-indicates the unit
-number in the range 0-3.
-While it may seem overkill, it is in fact
-sometimes useful to configure multiple reference clocks of the same
-type, in which case the unit numbers must be unique.
-.PP
-The
-.Ic server
-command is used to configure a reference
-clock, where the
-\fIaddress\fR
-argument in that command
-is the clock address.
-The
-.Cm key ,
-.Cm version
-and
-.Cm ttl
-options are not used for reference clock support.
-The
-.Cm mode
-option is added for reference clock support, as
-described below.
-The
-.Cm prefer
-option can be useful to
-persuade the server to cherish a reference clock with somewhat more
-enthusiasm than other reference clocks or peers.
-Further
-information on this option can be found in the
-.Qq Mitigation Rules and the prefer Keyword
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-page.
-The
-.Cm minpoll
-and
-.Cm maxpoll
-options have
-meaning only for selected clock drivers.
-See the individual clock
-driver document pages for additional information.
-.PP
-The
-.Ic fudge
-command is used to provide additional
-information for individual clock drivers and normally follows
-immediately after the
-.Ic server
-command.
-The
-\fIaddress\fR
-argument specifies the clock address.
-The
-.Cm refid
-and
-.Cm stratum
-options can be used to
-override the defaults for the device.
-There are two optional
-device-dependent time offsets and four flags that can be included
-in the
-.Ic fudge
-command as well.
-.PP
-The stratum number of a reference clock is by default zero.
-Since the
-.Xr ntpd 1ntpdmdoc
-daemon adds one to the stratum of each
-peer, a primary server ordinarily displays an external stratum of
-one.
-In order to provide engineered backups, it is often useful to
-specify the reference clock stratum as greater than zero.
-The
-.Cm stratum
-option is used for this purpose.
-Also, in cases
-involving both a reference clock and a pulse-per-second (PPS)
-discipline signal, it is useful to specify the reference clock
-identifier as other than the default, depending on the driver.
-The
-.Cm refid
-option is used for this purpose.
-Except where noted,
-these options apply to all clock drivers.
-.SS Reference Clock Commands
-.TP
-.BR Xo Ic server
-.Sm off
-.Li 127.127. Ar t . Ar u
-.Sm on
-[ "\fIprefer\fR" ]
-[ "\fImode\fR" "\fIint\fR" ]
-[ "\fIminpoll\fR" "\fIint\fR" ]
-[ "\fImaxpoll\fR" "\fIint\fR" ]
-.Xc
-This command can be used to configure reference clocks in
-special ways.
-The options are interpreted as follows:
-.in +4
-.ti -4
-.IR Cm prefer
-Marks the reference clock as preferred.
-All other things being
-equal, this host will be chosen for synchronization among a set of
-correctly operating hosts.
-See the
-.Qq Mitigation Rules and the prefer Keyword
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-for further information.
-.ti -4
-.IR Cm mode Ar int
-Specifies a mode number which is interpreted in a
-device-specific fashion.
-For instance, it selects a dialing
-protocol in the ACTS driver and a device subtype in the
-parse
-drivers.
-.ti -4
-.IR Cm minpoll Ar int
-.ti -4
-.IR Cm maxpoll Ar int
-These options specify the minimum and maximum polling interval
-for reference clock messages, as a power of 2 in seconds
-For
-most directly connected reference clocks, both
-.Cm minpoll
-and
-.Cm maxpoll
-default to 6 (64 s).
-For modem reference clocks,
-.Cm minpoll
-defaults to 10 (17.1 m) and
-.Cm maxpoll
-defaults to 14 (4.5 h).
-The allowable range is 4 (16 s) to 17 (36.4 h) inclusive.
-.in -4
-.TP
-.BR Xo Ic fudge
-.Sm off
-.Li 127.127. Ar t . Ar u
-.Sm on
-[ "\fItime1\fR" "\fIsec\fR" ]
-[ "\fItime2\fR" "\fIsec\fR" ]
-[ "\fIstratum\fR" "\fIint\fR" ]
-[ "\fIrefid\fR" "\fIstring\fR" ]
-[ "\fImode\fR" "\fIint\fR" ]
-[ "\fIflag1\fR" "\fI0\fR" \&| "\fI1\fR" ]
-[ "\fIflag2\fR" "\fI0\fR" \&| "\fI1\fR" ]
-[ "\fIflag3\fR" "\fI0\fR" \&| "\fI1\fR" ]
-[ "\fIflag4\fR" "\fI0\fR" \&| "\fI1\fR" ]
-.Xc
-This command can be used to configure reference clocks in
-special ways.
-It must immediately follow the
-.Ic server
-command which configures the driver.
-Note that the same capability
-is possible at run time using the
-.Xr ntpdc 1ntpdcmdoc
-program.
-The options are interpreted as
-follows:
-.in +4
-.ti -4
-.IR Cm time1 Ar sec
-Specifies a constant to be added to the time offset produced by
-the driver, a fixed-point decimal number in seconds.
-This is used
-as a calibration constant to adjust the nominal time offset of a
-particular clock to agree with an external standard, such as a
-precision PPS signal.
-It also provides a way to correct a
-systematic error or bias due to serial port or operating system
-latencies, different cable lengths or receiver internal delay.
-The
-specified offset is in addition to the propagation delay provided
-by other means, such as internal DIPswitches.
-Where a calibration
-for an individual system and driver is available, an approximate
-correction is noted in the driver documentation pages.
-Note: in order to facilitate calibration when more than one
-radio clock or PPS signal is supported, a special calibration
-feature is available.
-It takes the form of an argument to the
-.Ic enable
-command described in
-.Sx Miscellaneous Options
-page and operates as described in the
-.Qq Reference Clock Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.ti -4
-.IR Cm time2 Ar secs
-Specifies a fixed-point decimal number in seconds, which is
-interpreted in a driver-dependent way.
-See the descriptions of
-specific drivers in the
-.Qq Reference Clock Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.ti -4
-.IR Cm stratum Ar int
-Specifies the stratum number assigned to the driver, an integer
-between 0 and 15.
-This number overrides the default stratum number
-ordinarily assigned by the driver itself, usually zero.
-.ti -4
-.IR Cm refid Ar string
-Specifies an ASCII string of from one to four characters which
-defines the reference identifier used by the driver.
-This string
-overrides the default identifier ordinarily assigned by the driver
-itself.
-.ti -4
-.IR Cm mode Ar int
-Specifies a mode number which is interpreted in a
-device-specific fashion.
-For instance, it selects a dialing
-protocol in the ACTS driver and a device subtype in the
-parse
-drivers.
-.ti -4
-.IR Cm flag1 Cm 0 \&| Cm 1
-.ti -4
-.IR Cm flag2 Cm 0 \&| Cm 1
-.ti -4
-.IR Cm flag3 Cm 0 \&| Cm 1
-.ti -4
-.IR Cm flag4 Cm 0 \&| Cm 1
-These four flags are used for customizing the clock driver.
-The
-interpretation of these values, and whether they are used at all,
-is a function of the particular clock driver.
-However, by
-convention
-.Cm flag4
-is used to enable recording monitoring
-data to the
-.Cm clockstats
-file configured with the
-.Ic filegen
-command.
-Further information on the
-.Ic filegen
-command can be found in
-.Sx Monitoring Options .
-.in -4
-.SH Miscellaneous Options
-.TP
-.BR Ic broadcastdelay Ar seconds
-The broadcast and multicast modes require a special calibration
-to determine the network delay between the local and remote
-servers.
-Ordinarily, this is done automatically by the initial
-protocol exchanges between the client and server.
-In some cases,
-the calibration procedure may fail due to network or server access
-controls, for example.
-This command specifies the default delay to
-be used under these circumstances.
-Typically (for Ethernet), a
-number between 0.003 and 0.007 seconds is appropriate.
-The default
-when this command is not used is 0.004 seconds.
-.TP
-.BR Ic calldelay Ar delay
-This option controls the delay in seconds between the first and second
-packets sent in burst or iburst mode to allow additional time for a modem
-or ISDN call to complete.
-.TP
-.BR Ic driftfile Ar driftfile
-This command specifies the complete path and name of the file used to
-record the frequency of the local clock oscillator.
-This is the same
-operation as the
-f
-command line option.
-If the file exists, it is read at
-startup in order to set the initial frequency and then updated once per
-hour with the current frequency computed by the daemon.
-If the file name is
-specified, but the file itself does not exist, the starts with an initial
-frequency of zero and creates the file when writing it for the first time.
-If this command is not given, the daemon will always start with an initial
-frequency of zero.
-.PP
-The file format consists of a single line containing a single
-floating point number, which records the frequency offset measured
-in parts-per-million (PPM).
-The file is updated by first writing
-the current drift value into a temporary file and then renaming
-this file to replace the old version.
-This implies that
-.Xr ntpd 1ntpdmdoc
-must have write permission for the directory the
-drift file is located in, and that file system links, symbolic or
-otherwise, should be avoided.
-.TP
-.BR Xo Ic enable
-.Oo
-.Cm auth | Cm bclient |
-.Cm calibrate | Cm kernel |
-.Cm monitor | Cm ntp |
-.Cm pps | Cm stats
-.Oc
-.Xc
-.TP
-.BR Xo Ic disable
-.Oo
-.Cm auth | Cm bclient |
-.Cm calibrate | Cm kernel |
-.Cm monitor | Cm ntp |
-.Cm pps | Cm stats
-.Oc
-.Xc
-Provides a way to enable or disable various server options.
-Flags not mentioned are unaffected.
-Note that all of these flags
-can be controlled remotely using the
-.Xr ntpdc 1ntpdcmdoc
-utility program.
-.in +4
-.ti -4
-.IR Cm auth
-Enables the server to synchronize with unconfigured peers only if the
-peer has been correctly authenticated using either public key or
-private key cryptography.
-The default for this flag is
-.Ic enable .
-.ti -4
-.IR Cm bclient
-Enables the server to listen for a message from a broadcast or
-multicast server, as in the
-.Ic multicastclient
-command with default
-address.
-The default for this flag is
-.Ic disable .
-.ti -4
-.IR Cm calibrate
-Enables the calibrate feature for reference clocks.
-The default for
-this flag is
-.Ic disable .
-.ti -4
-.IR Cm kernel
-Enables the kernel time discipline, if available.
-The default for this
-flag is
-.Ic enable
-if support is available, otherwise
-.Ic disable .
-.ti -4
-.IR Cm monitor
-Enables the monitoring facility.
-See the
-.Xr ntpdc 1ntpdcmdoc
-program
-and the
-.Ic monlist
-command or further information.
-The
-default for this flag is
-.Ic enable .
-.ti -4
-.IR Cm ntp
-Enables time and frequency discipline.
-In effect, this switch opens and
-closes the feedback loop, which is useful for testing.
-The default for
-this flag is
-.Ic enable .
-.ti -4
-.IR Cm pps
-Enables the pulse-per-second (PPS) signal when frequency and time is
-disciplined by the precision time kernel modifications.
-See the
-.Qq A Kernel Model for Precision Timekeeping
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-page for further information.
-The default for this flag is
-.Ic disable .
-.ti -4
-.IR Cm stats
-Enables the statistics facility.
-See the
-.Sx Monitoring Options
-section for further information.
-The default for this flag is
-.Ic disable .
-.in -4
-.TP
-.BR Ic includefile Ar includefile
-This command allows additional configuration commands
-to be included from a separate file.
-Include files may
-be nested to a depth of five; upon reaching the end of any
-include file, command processing resumes in the previous
-configuration file.
-This option is useful for sites that run
-.Xr ntpd 1ntpdmdoc
-on multiple hosts, with (mostly) common options (e.g., a
-restriction list).
-.TP
-.BR Ic logconfig Ar configkeyword
-This command controls the amount and type of output written to
-the system
-.Xr syslog 3
-facility or the alternate
-.Ic logfile
-log file.
-By default, all output is turned on.
-All
-\fIconfigkeyword\fR
-keywords can be prefixed with
-.Ql = ,
-.Ql +
-and
-.Ql - ,
-where
-.Ql =
-sets the
-.Xr syslog 3
-priority mask,
-.Ql +
-adds and
-.Ql -
-removes
-messages.
-.Xr syslog 3
-messages can be controlled in four
-classes
-.Po
-.Cm clock ,
-.Cm peer ,
-.Cm sys
-and
-.Cm sync
-.Pc .
-Within these classes four types of messages can be
-controlled: informational messages
-.Po
-.Cm info
-.Pc ,
-event messages
-.Po
-.Cm events
-.Pc ,
-statistics messages
-.Po
-.Cm statistics
-.Pc
-and
-status messages
-.Po
-.Cm status
-.Pc .
-.PP
-Configuration keywords are formed by concatenating the message class with
-the event class.
-The
-.Cm all
-prefix can be used instead of a message class.
-A
-message class may also be followed by the
-.Cm all
-keyword to enable/disable all
-messages of the respective message class.Thus, a minimal log configuration
-could look like this:
-.br
-.in +4
-.nf
-logconfig =syncstatus +sysevents
-.in -4
-.fi
-.PP
-This would just list the synchronizations state of
-.Xr ntpd 1ntpdmdoc
-and the major system events.
-For a simple reference server, the
-following minimum message configuration could be useful:
-.br
-.in +4
-.nf
-logconfig =syncall +clockall
-.in -4
-.fi
-.PP
-This configuration will list all clock information and
-synchronization information.
-All other events and messages about
-peers, system events and so on is suppressed.
-.TP
-.BR Ic logfile Ar logfile
-This command specifies the location of an alternate log file to
-be used instead of the default system
-.Xr syslog 3
-facility.
-This is the same operation as the -l command line option.
-.TP
-.BR Ic setvar Ar variable Op Cm default
-This command adds an additional system variable.
-These
-variables can be used to distribute additional information such as
-the access policy.
-If the variable of the form
-.Sm off
-.Va name = Ar value
-.Sm on
-is followed by the
-.Cm default
-keyword, the
-variable will be listed as part of the default system variables
-.Po
-.Xr ntpq 1ntpqmdoc
-.Ic rv
-command
-.Pc ) .
-These additional variables serve
-informational purposes only.
-They are not related to the protocol
-other that they can be listed.
-The known protocol variables will
-always override any variables defined via the
-.Ic setvar
-mechanism.
-There are three special variables that contain the names
-of all variable of the same group.
-The
-.Va sys_var_list
-holds
-the names of all system variables.
-The
-.Va peer_var_list
-holds
-the names of all peer variables and the
-.Va clock_var_list
-holds the names of the reference clock variables.
-.TP
-.BR Xo Ic tinker
-.Oo
-.Cm allan Ar allan |
-.Cm dispersion Ar dispersion |
-.Cm freq Ar freq |
-.Cm huffpuff Ar huffpuff |
-.Cm panic Ar panic |
-.Cm step Ar srep |
-.Cm stepout Ar stepout
-.Oc
-.Xc
-This command can be used to alter several system variables in
-very exceptional circumstances.
-It should occur in the
-configuration file before any other configuration options.
-The
-default values of these variables have been carefully optimized for
-a wide range of network speeds and reliability expectations.
-In
-general, they interact in intricate ways that are hard to predict
-and some combinations can result in some very nasty behavior.
-Very
-rarely is it necessary to change the default values; but, some
-folks cannot resist twisting the knobs anyway and this command is
-for them.
-Emphasis added: twisters are on their own and can expect
-no help from the support group.
-.PP
-The variables operate as follows:
-.in +4
-.ti -4
-.IR Cm allan Ar allan
-The argument becomes the new value for the minimum Allan
-intercept, which is a parameter of the PLL/FLL clock discipline
-algorithm.
-The value in log2 seconds defaults to 7 (1024 s), which is also the lower
-limit.
-.ti -4
-.IR Cm dispersion Ar dispersion
-The argument becomes the new value for the dispersion increase rate,
-normally .000015 s/s.
-.ti -4
-.IR Cm freq Ar freq
-The argument becomes the initial value of the frequency offset in
-parts-per-million.
-This overrides the value in the frequency file, if
-present, and avoids the initial training state if it is not.
-.ti -4
-.IR Cm huffpuff Ar huffpuff
-The argument becomes the new value for the experimental
-huff-n'-puff filter span, which determines the most recent interval
-the algorithm will search for a minimum delay.
-The lower limit is
-900 s (15 m), but a more reasonable value is 7200 (2 hours).
-There
-is no default, since the filter is not enabled unless this command
-is given.
-.ti -4
-.IR Cm panic Ar panic
-The argument is the panic threshold, normally 1000 s.
-If set to zero,
-the panic sanity check is disabled and a clock offset of any value will
-be accepted.
-.ti -4
-.IR Cm step Ar step
-The argument is the step threshold, which by default is 0.128 s.
-It can
-be set to any positive number in seconds.
-If set to zero, step
-adjustments will never occur.
-Note: The kernel time discipline is
-disabled if the step threshold is set to zero or greater than the
-default.
-.ti -4
-.IR Cm stepout Ar stepout
-The argument is the stepout timeout, which by default is 900 s.
-It can
-be set to any positive number in seconds.
-If set to zero, the stepout
-pulses will not be suppressed.
-.in -4
-.TP
-.BR Xo Ic trap Ar host_address
-[ "\fIport\fR" "\fIport_number\fR" ]
-[ "\fIinterface\fR" "\fIinterface_address\fR" ]
-.Xc
-This command configures a trap receiver at the given host
-address and port number for sending messages with the specified
-local interface address.
-If the port number is unspecified, a value
-of 18447 is used.
-If the interface address is not specified, the
-message is sent with a source address of the local interface the
-message is sent through.
-Note that on a multihomed host the
-interface used may vary from time to time with routing changes.
-.PP
-The trap receiver will generally log event messages and other
-information from the server in a log file.
-While such monitor
-programs may also request their own trap dynamically, configuring a
-trap receiver will ensure that no messages are lost when the server
-is started.
-.TP
-.BR Cm hop Ar ...
-This command specifies a list of TTL values in increasing order, up to 8
-values can be specified.
-In manycast mode these values are used in turn in
-an expanding-ring search.
-The default is eight multiples of 32 starting at
-31.
.SH FILES
-.TP
-.BR Pa /etc/ntp.conf
-the default name of the configuration file
-.TP
-.BR Pa ntp.keys
-private MD5 keys
-.TP
-.BR Pa ntpkey
-RSA private key
-.TP
-.BR Pa ntpkey_ Ns Ar host
-RSA public key
-.TP
-.BR Pa ntp_dh
-Diffie-Hellman agreement parameters
.SH "SEE ALSO"
-.SH SEE ALSO
-.Xr ntpd 1ntpdmdoc ,
-.Xr ntpdc 1ntpdcmdoc ,
-.Xr ntpq 1ntpqmdoc
-.PP
-In addition to the manual pages provided,
-comprehensive documentation is available on the world wide web
-at
-.Li http://www.ntp.org/ .
-A snapshot of this documentation is available in HTML format in
-.Pa /usr/share/doc/ntp .
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 4)
-.%O RFC5905
-.Re
.SH "AUTHORS"
The University of Delaware
.SH "COPYRIGHT"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.SH BUGS
-The syntax checking is not picky; some combinations of
-ridiculous and even hilarious options and modes may not be
-detected.
-.PP
-The
-.Pa ntpkey_ Ns Ar host
-files are really digital
-certificates.
-These should be obtained via secure directory
-services when they become universally available.Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
+Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.SH NOTES
-This document is derived from FreeBSD.
.PP
This manual page was \fIAutoGen\fP-erated from the \fBntp.conf\fP
option definitions.
-.Dd December 5 2012
+.Dd December 6 2012
.Dt NTP_CONF 5mdoc File Formats
-.Os FreeBSD 6.4-STABLE
+.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp.mdoc)
.\"
-.\" It has been AutoGen-ed December 5, 2012 at 10:45:51 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:25 AM by AutoGen 5.16.2
.\" From the definitions ntp.conf.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
All arguments must be options.
.Pp
.Sh DESCRIPTION
-The
-.Nm
-configuration file is read at initial startup by the
-.Xr ntpd 1ntpdmdoc
-daemon in order to specify the synchronization sources,
-modes and other related information.
-Usually, it is installed in the
-.Pa /etc
-directory,
-but could be installed elsewhere
-(see the daemon's
-.Fl c
-command line option).
-.Pp
-The file format is similar to other
-.Ux
-configuration files.
-Comments begin with a
-.Ql #
-character and extend to the end of the line;
-blank lines are ignored.
-Configuration commands consist of an initial keyword
-followed by a list of arguments,
-some of which may be optional, separated by whitespace.
-Commands may not be continued over multiple lines.
-Arguments may be host names,
-host addresses written in numeric, dotted-quad form,
-integers, floating point numbers (when specifying times in seconds)
-and text strings.
-.Pp
-The rest of this page describes the configuration and control options.
-The
-.Qq Notes on Configuring NTP and Setting up a NTP Subnet
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-contains an extended discussion of these options.
-In addition to the discussion of general
-.Sx Configuration Options ,
-there are sections describing the following supported functionality
-and the options used to control it:
-.Bl -bullet -offset indent
-.It
-.Sx Authentication Support
-.It
-.Sx Monitoring Support
-.It
-.Sx Access Control Support
-.It
-.Sx Automatic NTP Configuration Options
-.It
-.Sx Reference Clock Support
-.It
-.Sx Miscellaneous Options
-.El
-.Pp
-Following these is a section describing
-.Sx Miscellaneous Options .
-While there is a rich set of options available,
-the only required option is one or more
-.Ic pool ,
-.Ic server ,
-.Ic peer ,
-.Ic broadcast
-or
-.Ic manycastclient
-commands.
-.Sh Configuration Support
-Following is a description of the configuration commands in
-NTPv4.
-These commands have the same basic functions as in NTPv3 and
-in some cases new functions and new arguments.
-There are two
-classes of commands, configuration commands that configure a
-persistent association with a remote server or peer or reference
-clock, and auxiliary commands that specify environmental variables
-that control various related operations.
-.Ss Configuration Commands
-The various modes are determined by the command keyword and the
-type of the required IP address.
-Addresses are classed by type as
-(s) a remote server or peer (IPv4 class A, B and C), (b) the
-broadcast address of a local interface, (m) a multicast address (IPv4
-class D), or (r) a reference clock address (127.127.x.x).
-Note that
-only those options applicable to each command are listed below.
-Use
-of options not listed may not be caught as an error, but may result
-in some weird and even destructive behavior.
-.Pp
-If the Basic Socket Interface Extensions for IPv6 (RFC-2553)
-is detected, support for the IPv6 address family is generated
-in addition to the default support of the IPv4 address family.
-In a few cases, including the reslist billboard generated
-by ntpdc, IPv6 addresses are automatically generated.
-IPv6 addresses can be identified by the presence of colons
-.Dq \&:
-in the address field.
-IPv6 addresses can be used almost everywhere where
-IPv4 addresses can be used,
-with the exception of reference clock addresses,
-which are always IPv4.
-.Pp
-Note that in contexts where a host name is expected, a
-.Fl 4
-qualifier preceding
-the host name forces DNS resolution to the IPv4 namespace,
-while a
-.Fl 6
-qualifier forces DNS resolution to the IPv6 namespace.
-See IPv6 references for the
-equivalent classes for that address family.
-.Bl -tag -width indent
-.It Xo Ic pool Ar address
-.Op Cm burst
-.Op Cm iburst
-.Op Cm version Ar version
-.Op Cm prefer
-.Op Cm minpoll Ar minpoll
-.Op Cm maxpoll Ar maxpoll
-.Xc
-.It Xo Ic server Ar address
-.Op Cm key Ar key \&| Cm autokey
-.Op Cm burst
-.Op Cm iburst
-.Op Cm version Ar version
-.Op Cm prefer
-.Op Cm minpoll Ar minpoll
-.Op Cm maxpoll Ar maxpoll
-.Xc
-.It Xo Ic peer Ar address
-.Op Cm key Ar key \&| Cm autokey
-.Op Cm version Ar version
-.Op Cm prefer
-.Op Cm minpoll Ar minpoll
-.Op Cm maxpoll Ar maxpoll
-.Xc
-.It Xo Ic broadcast Ar address
-.Op Cm key Ar key \&| Cm autokey
-.Op Cm version Ar version
-.Op Cm prefer
-.Op Cm minpoll Ar minpoll
-.Op Cm ttl Ar ttl
-.Xc
-.It Xo Ic manycastclient Ar address
-.Op Cm key Ar key \&| Cm autokey
-.Op Cm version Ar version
-.Op Cm prefer
-.Op Cm minpoll Ar minpoll
-.Op Cm maxpoll Ar maxpoll
-.Op Cm ttl Ar ttl
-.Xc
-.El
-.Pp
-These five commands specify the time server name or address to
-be used and the mode in which to operate.
-The
-.Ar address
-can be
-either a DNS name or an IP address in dotted-quad notation.
-Additional information on association behavior can be found in the
-.Qq Association Management
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.Bl -tag -width indent
-.It Ic pool
-For type s addresses, this command mobilizes a persistent
-client mode association with a number of remote servers.
-In this mode the local clock can synchronized to the
-remote server, but the remote server can never be synchronized to
-the local clock.
-.It Ic server
-For type s and r addresses, this command mobilizes a persistent
-client mode association with the specified remote server or local
-radio clock.
-In this mode the local clock can synchronized to the
-remote server, but the remote server can never be synchronized to
-the local clock.
-This command should
-.Em not
-be used for type
-b or m addresses.
-.It Ic peer
-For type s addresses (only), this command mobilizes a
-persistent symmetric-active mode association with the specified
-remote peer.
-In this mode the local clock can be synchronized to
-the remote peer or the remote peer can be synchronized to the local
-clock.
-This is useful in a network of servers where, depending on
-various failure scenarios, either the local or remote peer may be
-the better source of time.
-This command should NOT be used for type
-b, m or r addresses.
-.It Ic broadcast
-For type b and m addresses (only), this
-command mobilizes a persistent broadcast mode association.
-Multiple
-commands can be used to specify multiple local broadcast interfaces
-(subnets) and/or multiple multicast groups.
-Note that local
-broadcast messages go only to the interface associated with the
-subnet specified, but multicast messages go to all interfaces.
-In broadcast mode the local server sends periodic broadcast
-messages to a client population at the
-.Ar address
-specified, which is usually the broadcast address on (one of) the
-local network(s) or a multicast address assigned to NTP.
-The IANA
-has assigned the multicast group address IPv4 224.0.1.1 and
-IPv6 ff05::101 (site local) exclusively to
-NTP, but other nonconflicting addresses can be used to contain the
-messages within administrative boundaries.
-Ordinarily, this
-specification applies only to the local server operating as a
-sender; for operation as a broadcast client, see the
-.Ic broadcastclient
-or
-.Ic multicastclient
-commands
-below.
-.It Ic manycastclient
-For type m addresses (only), this command mobilizes a
-manycast client mode association for the multicast address
-specified.
-In this case a specific address must be supplied which
-matches the address used on the
-.Ic manycastserver
-command for
-the designated manycast servers.
-The NTP multicast address
-224.0.1.1 assigned by the IANA should NOT be used, unless specific
-means are taken to avoid spraying large areas of the Internet with
-these messages and causing a possibly massive implosion of replies
-at the sender.
-The
-.Ic manycastserver
-command specifies that the local server
-is to operate in client mode with the remote servers that are
-discovered as the result of broadcast/multicast messages.
-The
-client broadcasts a request message to the group address associated
-with the specified
-.Ar address
-and specifically enabled
-servers respond to these messages.
-The client selects the servers
-providing the best time and continues as with the
-.Ic server
-command.
-The remaining servers are discarded as if never
-heard.
-.El
-.Pp
-Options:
-.Bl -tag -width indent
-.It Cm autokey
-All packets sent to and received from the server or peer are to
-include authentication fields encrypted using the autokey scheme
-described in
-.Sx Authentication Options .
-.It Cm burst
-when the server is reachable, send a burst of eight packets
-instead of the usual one.
-The packet spacing is normally 2 s;
-however, the spacing between the first and second packets
-can be changed with the calldelay command to allow
-additional time for a modem or ISDN call to complete.
-This is designed to improve timekeeping quality
-with the
-.Ic server
-command and s addresses.
-.It Cm iburst
-When the server is unreachable, send a burst of eight packets
-instead of the usual one.
-The packet spacing is normally 2 s;
-however, the spacing between the first two packets can be
-changed with the calldelay command to allow
-additional time for a modem or ISDN call to complete.
-This is designed to speed the initial synchronization
-acquisition with the
-.Ic server
-command and s addresses and when
-.Xr ntpd 1ntpdmdoc
-is started with the
-.Fl q
-option.
-.It Cm key Ar key
-All packets sent to and received from the server or peer are to
-include authentication fields encrypted using the specified
-.Ar key
-identifier with values from 1 to 65534, inclusive.
-The
-default is to include no encryption field.
-.It Cm minpoll Ar minpoll
-.It Cm maxpoll Ar maxpoll
-These options specify the minimum and maximum poll intervals
-for NTP messages, as a power of 2 in seconds
-The maximum poll
-interval defaults to 10 (1,024 s), but can be increased by the
-.Cm maxpoll
-option to an upper limit of 17 (36.4 h).
-The
-minimum poll interval defaults to 6 (64 s), but can be decreased by
-the
-.Cm minpoll
-option to a lower limit of 4 (16 s).
-.It Cm noselect
-Marks the server as unused, except for display purposes.
-The server is discarded by the selection algroithm.
-.It Cm prefer
-Marks the server as preferred.
-All other things being equal,
-this host will be chosen for synchronization among a set of
-correctly operating hosts.
-See the
-.Qq Mitigation Rules and the prefer Keyword
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-for further information.
-.It Cm ttl Ar ttl
-This option is used only with broadcast server and manycast
-client modes.
-It specifies the time-to-live
-.Ar ttl
-to
-use on broadcast server and multicast server and the maximum
-.Ar ttl
-for the expanding ring search with manycast
-client packets.
-Selection of the proper value, which defaults to
-127, is something of a black art and should be coordinated with the
-network administrator.
-.It Cm version Ar version
-Specifies the version number to be used for outgoing NTP
-packets.
-Versions 1-4 are the choices, with version 4 the
-default.
-.El
-.Ss Auxiliary Commands
-.Bl -tag -width indent
-.It Ic broadcastclient
-This command enables reception of broadcast server messages to
-any local interface (type b) address.
-Upon receiving a message for
-the first time, the broadcast client measures the nominal server
-propagation delay using a brief client/server exchange with the
-server, then enters the broadcast client mode, in which it
-synchronizes to succeeding broadcast messages.
-Note that, in order
-to avoid accidental or malicious disruption in this mode, both the
-server and client should operate using symmetric-key or public-key
-authentication as described in
-.Sx Authentication Options .
-.It Ic manycastserver Ar address ...
-This command enables reception of manycast client messages to
-the multicast group address(es) (type m) specified.
-At least one
-address is required, but the NTP multicast address 224.0.1.1
-assigned by the IANA should NOT be used, unless specific means are
-taken to limit the span of the reply and avoid a possibly massive
-implosion at the original sender.
-Note that, in order to avoid
-accidental or malicious disruption in this mode, both the server
-and client should operate using symmetric-key or public-key
-authentication as described in
-.Sx Authentication Options .
-.It Ic multicastclient Ar address ...
-This command enables reception of multicast server messages to
-the multicast group address(es) (type m) specified.
-Upon receiving
-a message for the first time, the multicast client measures the
-nominal server propagation delay using a brief client/server
-exchange with the server, then enters the broadcast client mode, in
-which it synchronizes to succeeding multicast messages.
-Note that,
-in order to avoid accidental or malicious disruption in this mode,
-both the server and client should operate using symmetric-key or
-public-key authentication as described in
-.Sx Authentication Options .
-.El
-.Sh Authentication Support
-Authentication support allows the NTP client to verify that the
-server is in fact known and trusted and not an intruder intending
-accidentally or on purpose to masquerade as that server.
-The NTPv3
-specification RFC-1305 defines a scheme which provides
-cryptographic authentication of received NTP packets.
-Originally,
-this was done using the Data Encryption Standard (DES) algorithm
-operating in Cipher Block Chaining (CBC) mode, commonly called
-DES-CBC.
-Subsequently, this was replaced by the RSA Message Digest
-5 (MD5) algorithm using a private key, commonly called keyed-MD5.
-Either algorithm computes a message digest, or one-way hash, which
-can be used to verify the server has the correct private key and
-key identifier.
-.Pp
-NTPv4 retains the NTPv3 scheme, properly described as symmetric key
-cryptography and, in addition, provides a new Autokey scheme
-based on public key cryptography.
-Public key cryptography is generally considered more secure
-than symmetric key cryptography, since the security is based
-on a private value which is generated by each server and
-never revealed.
-With Autokey all key distribution and
-management functions involve only public values, which
-considerably simplifies key distribution and storage.
-Public key management is based on X.509 certificates,
-which can be provided by commercial services or
-produced by utility programs in the OpenSSL software library
-or the NTPv4 distribution.
-.Pp
-While the algorithms for symmetric key cryptography are
-included in the NTPv4 distribution, public key cryptography
-requires the OpenSSL software library to be installed
-before building the NTP distribution.
-Directions for doing that
-are on the Building and Installing the Distribution page.
-.Pp
-Authentication is configured separately for each association
-using the
-.Cm key
-or
-.Cm autokey
-subcommand on the
-.Ic peer ,
-.Ic server ,
-.Ic broadcast
-and
-.Ic manycastclient
-configuration commands as described in
-.Sx Configuration Options
-page.
-The authentication
-options described below specify the locations of the key files,
-if other than default, which symmetric keys are trusted
-and the interval between various operations, if other than default.
-.Pp
-Authentication is always enabled,
-although ineffective if not configured as
-described below.
-If a NTP packet arrives
-including a message authentication
-code (MAC), it is accepted only if it
-passes all cryptographic checks.
-The
-checks require correct key ID, key value
-and message digest.
-If the packet has
-been modified in any way or replayed
-by an intruder, it will fail one or more
-of these checks and be discarded.
-Furthermore, the Autokey scheme requires a
-preliminary protocol exchange to obtain
-the server certificate, verify its
-credentials and initialize the protocol
-.Pp
-The
-.Cm auth
-flag controls whether new associations or
-remote configuration commands require cryptographic authentication.
-This flag can be set or reset by the
-.Ic enable
-and
-.Ic disable
-commands and also by remote
-configuration commands sent by a
-.Xr ntpdc 1ntpdcmdoc
-program running in
-another machine.
-If this flag is enabled, which is the default
-case, new broadcast client and symmetric passive associations and
-remote configuration commands must be cryptographically
-authenticated using either symmetric key or public key cryptography.
-If this
-flag is disabled, these operations are effective
-even if not cryptographic
-authenticated.
-It should be understood
-that operating with the
-.Ic auth
-flag disabled invites a significant vulnerability
-where a rogue hacker can
-masquerade as a falseticker and seriously
-disrupt system timekeeping.
-It is
-important to note that this flag has no purpose
-other than to allow or disallow
-a new association in response to new broadcast
-and symmetric active messages
-and remote configuration commands and, in particular,
-the flag has no effect on
-the authentication process itself.
-.Pp
-An attractive alternative where multicast support is available
-is manycast mode, in which clients periodically troll
-for servers as described in the
-.Sx Automatic NTP Configuration Options
-page.
-Either symmetric key or public key
-cryptographic authentication can be used in this mode.
-The principle advantage
-of manycast mode is that potential servers need not be
-configured in advance,
-since the client finds them during regular operation,
-and the configuration
-files for all clients can be identical.
-.Pp
-The security model and protocol schemes for
-both symmetric key and public key
-cryptography are summarized below;
-further details are in the briefings, papers
-and reports at the NTP project page linked from
-.Li http://www.ntp.org/ .
-.Ss Symmetric-Key Cryptography
-The original RFC-1305 specification allows any one of possibly
-65,534 keys, each distinguished by a 32-bit key identifier, to
-authenticate an association.
-The servers and clients involved must
-agree on the key and key identifier to
-authenticate NTP packets.
-Keys and
-related information are specified in a key
-file, usually called
-.Pa ntp.keys ,
-which must be distributed and stored using
-secure means beyond the scope of the NTP protocol itself.
-Besides the keys used
-for ordinary NTP associations,
-additional keys can be used as passwords for the
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-utility programs.
-.Pp
-When
-.Xr ntpd 1ntpdmdoc
-is first started, it reads the key file specified in the
-.Ic keys
-configuration command and installs the keys
-in the key cache.
-However,
-individual keys must be activated with the
-.Ic trusted
-command before use.
-This
-allows, for instance, the installation of possibly
-several batches of keys and
-then activating or deactivating each batch
-remotely using
-.Xr ntpdc 1ntpdcmdoc .
-This also provides a revocation capability that can be used
-if a key becomes compromised.
-The
-.Ic requestkey
-command selects the key used as the password for the
-.Xr ntpdc 1ntpdcmdoc
-utility, while the
-.Ic controlkey
-command selects the key used as the password for the
-.Xr ntpq 1ntpqmdoc
-utility.
-.Ss Public Key Cryptography
-NTPv4 supports the original NTPv3 symmetric key scheme
-described in RFC-1305 and in addition the Autokey protocol,
-which is based on public key cryptography.
-The Autokey Version 2 protocol described on the Autokey Protocol
-page verifies packet integrity using MD5 message digests
-and verifies the source with digital signatures and any of several
-digest/signature schemes.
-Optional identity schemes described on the Identity Schemes
-page and based on cryptographic challenge/response algorithms
-are also available.
-Using all of these schemes provides strong security against
-replay with or without modification, spoofing, masquerade
-and most forms of clogging attacks.
-.\" .Pp
-.\" The cryptographic means necessary for all Autokey operations
-.\" is provided by the OpenSSL software library.
-.\" This library is available from http://www.openssl.org/
-.\" and can be installed using the procedures outlined
-.\" in the Building and Installing the Distribution page.
-.\" Once installed,
-.\" the configure and build
-.\" process automatically detects the library and links
-.\" the library routines required.
-.Pp
-The Autokey protocol has several modes of operation
-corresponding to the various NTP modes supported.
-Most modes use a special cookie which can be
-computed independently by the client and server,
-but encrypted in transmission.
-All modes use in addition a variant of the S-KEY scheme,
-in which a pseudo-random key list is generated and used
-in reverse order.
-These schemes are described along with an executive summary,
-current status, briefing slides and reading list on the
-.Sx Autonomous Authentication
-page.
-.Pp
-The specific cryptographic environment used by Autokey servers
-and clients is determined by a set of files
-and soft links generated by the
-.Xr ntp-keygen 1ntpkeygenmdoc
-program.
-This includes a required host key file,
-required certificate file and optional sign key file,
-leapsecond file and identity scheme files.
-The
-digest/signature scheme is specified in the X.509 certificate
-along with the matching sign key.
-There are several schemes
-available in the OpenSSL software library, each identified
-by a specific string such as
-.Cm md5WithRSAEncryption ,
-which stands for the MD5 message digest with RSA
-encryption scheme.
-The current NTP distribution supports
-all the schemes in the OpenSSL library, including
-those based on RSA and DSA digital signatures.
-.Pp
-NTP secure groups can be used to define cryptographic compartments
-and security hierarchies.
-It is important that every host
-in the group be able to construct a certificate trail to one
-or more trusted hosts in the same group.
-Each group
-host runs the Autokey protocol to obtain the certificates
-for all hosts along the trail to one or more trusted hosts.
-This requires the configuration file in all hosts to be
-engineered so that, even under anticipated failure conditions,
-the NTP subnet will form such that every group host can find
-a trail to at least one trusted host.
-.Ss Naming and Addressing
-It is important to note that Autokey does not use DNS to
-resolve addresses, since DNS can't be completely trusted
-until the name servers have synchronized clocks.
-The cryptographic name used by Autokey to bind the host identity
-credentials and cryptographic values must be independent
-of interface, network and any other naming convention.
-The name appears in the host certificate in either or both
-the subject and issuer fields, so protection against
-DNS compromise is essential.
-.Pp
-By convention, the name of an Autokey host is the name returned
-by the Unix
-.Xr gethostname 2
-system call or equivalent in other systems.
-By the system design
-model, there are no provisions to allow alternate names or aliases.
-However, this is not to say that DNS aliases, different names
-for each interface, etc., are constrained in any way.
-.Pp
-It is also important to note that Autokey verifies authenticity
-using the host name, network address and public keys,
-all of which are bound together by the protocol specifically
-to deflect masquerade attacks.
-For this reason Autokey
-includes the source and destinatino IP addresses in message digest
-computations and so the same addresses must be available
-at both the server and client.
-For this reason operation
-with network address translation schemes is not possible.
-This reflects the intended robust security model where government
-and corporate NTP servers are operated outside firewall perimeters.
-.Ss Operation
-A specific combination of authentication scheme (none,
-symmetric key, public key) and identity scheme is called
-a cryptotype, although not all combinations are compatible.
-There may be management configurations where the clients,
-servers and peers may not all support the same cryptotypes.
-A secure NTPv4 subnet can be configured in many ways while
-keeping in mind the principles explained above and
-in this section.
-Note however that some cryptotype
-combinations may successfully interoperate with each other,
-but may not represent good security practice.
-.Pp
-The cryptotype of an association is determined at the time
-of mobilization, either at configuration time or some time
-later when a message of appropriate cryptotype arrives.
-When mobilized by a
-.Ic server
-or
-.Ic peer
-configuration command and no
-.Ic key
-or
-.Ic autokey
-subcommands are present, the association is not
-authenticated; if the
-.Ic key
-subcommand is present, the association is authenticated
-using the symmetric key ID specified; if the
-.Ic autokey
-subcommand is present, the association is authenticated
-using Autokey.
-.Pp
-When multiple identity schemes are supported in the Autokey
-protocol, the first message exchange determines which one is used.
-The client request message contains bits corresponding
-to which schemes it has available.
-The server response message
-contains bits corresponding to which schemes it has available.
-Both server and client match the received bits with their own
-and select a common scheme.
-.Pp
-Following the principle that time is a public value,
-a server responds to any client packet that matches
-its cryptotype capabilities.
-Thus, a server receiving
-an unauthenticated packet will respond with an unauthenticated
-packet, while the same server receiving a packet of a cryptotype
-it supports will respond with packets of that cryptotype.
-However, unconfigured broadcast or manycast client
-associations or symmetric passive associations will not be
-mobilized unless the server supports a cryptotype compatible
-with the first packet received.
-By default, unauthenticated associations will not be mobilized
-unless overridden in a decidedly dangerous way.
-.Pp
-Some examples may help to reduce confusion.
-Client Alice has no specific cryptotype selected.
-Server Bob has both a symmetric key file and minimal Autokey files.
-Alice's unauthenticated messages arrive at Bob, who replies with
-unauthenticated messages.
-Cathy has a copy of Bob's symmetric
-key file and has selected key ID 4 in messages to Bob.
-Bob verifies the message with his key ID 4.
-If it's the
-same key and the message is verified, Bob sends Cathy a reply
-authenticated with that key.
-If verification fails,
-Bob sends Cathy a thing called a crypto-NAK, which tells her
-something broke.
-She can see the evidence using the ntpq program.
-.Pp
-Denise has rolled her own host key and certificate.
-She also uses one of the identity schemes as Bob.
-She sends the first Autokey message to Bob and they
-both dance the protocol authentication and identity steps.
-If all comes out okay, Denise and Bob continue as described above.
-.Pp
-It should be clear from the above that Bob can support
-all the girls at the same time, as long as he has compatible
-authentication and identity credentials.
-Now, Bob can act just like the girls in his own choice of servers;
-he can run multiple configured associations with multiple different
-servers (or the same server, although that might not be useful).
-But, wise security policy might preclude some cryptotype
-combinations; for instance, running an identity scheme
-with one server and no authentication with another might not be wise.
-.Ss Key Management
-The cryptographic values used by the Autokey protocol are
-incorporated as a set of files generated by the
-.Xr ntp-keygen 1ntpkeygenmdoc
-utility program, including symmetric key, host key and
-public certificate files, as well as sign key, identity parameters
-and leapseconds files.
-Alternatively, host and sign keys and
-certificate files can be generated by the OpenSSL utilities
-and certificates can be imported from public certificate
-authorities.
-Note that symmetric keys are necessary for the
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-utility programs.
-The remaining files are necessary only for the
-Autokey protocol.
-.Pp
-Certificates imported from OpenSSL or public certificate
-authorities have certian limitations.
-The certificate should be in ASN.1 syntax, X.509 Version 3
-format and encoded in PEM, which is the same format
-used by OpenSSL.
-The overall length of the certificate encoded
-in ASN.1 must not exceed 1024 bytes.
-The subject distinguished
-name field (CN) is the fully qualified name of the host
-on which it is used; the remaining subject fields are ignored.
-The certificate extension fields must not contain either
-a subject key identifier or a issuer key identifier field;
-however, an extended key usage field for a trusted host must
-contain the value
-.Cm trustRoot ; .
-Other extension fields are ignored.
-.Ss Authentication Commands
-.Bl -tag -width indent
-.It Ic autokey Op Ar logsec
-Specifies the interval between regenerations of the session key
-list used with the Autokey protocol.
-Note that the size of the key
-list for each association depends on this interval and the current
-poll interval.
-The default value is 12 (4096 s or about 1.1 hours).
-For poll intervals above the specified interval, a session key list
-with a single entry will be regenerated for every message
-sent.
-.It Ic controlkey Ar key
-Specifies the key identifier to use with the
-.Xr ntpq 1ntpqmdoc
-utility, which uses the standard
-protocol defined in RFC-1305.
-The
-.Ar key
-argument is
-the key identifier for a trusted key, where the value can be in the
-range 1 to 65,534, inclusive.
-.It Xo Ic crypto
-.Op Cm cert Ar file
-.Op Cm leap Ar file
-.Op Cm randfile Ar file
-.Op Cm host Ar file
-.Op Cm sign Ar file
-.Op Cm gq Ar file
-.Op Cm gqpar Ar file
-.Op Cm iffpar Ar file
-.Op Cm mvpar Ar file
-.Op Cm pw Ar password
-.Xc
-This command requires the OpenSSL library.
-It activates public key
-cryptography, selects the message digest and signature
-encryption scheme and loads the required private and public
-values described above.
-If one or more files are left unspecified,
-the default names are used as described above.
-Unless the complete path and name of the file are specified, the
-location of a file is relative to the keys directory specified
-in the
-.Ic keysdir
-command or default
-.Pa /usr/local/etc .
-Following are the subcommands:
-.Bl -tag -width indent
-.It Cm cert Ar file
-Specifies the location of the required host public certificate file.
-This overrides the link
-.Pa ntpkey_cert_ Ns Ar hostname
-in the keys directory.
-.It Cm gqpar Ar file
-Specifies the location of the optional GQ parameters file.
-This
-overrides the link
-.Pa ntpkey_gq_ Ns Ar hostname
-in the keys directory.
-.It Cm host Ar file
-Specifies the location of the required host key file.
-This overrides
-the link
-.Pa ntpkey_key_ Ns Ar hostname
-in the keys directory.
-.It Cm iffpar Ar file
-Specifies the location of the optional IFF parameters file.This
-overrides the link
-.Pa ntpkey_iff_ Ns Ar hostname
-in the keys directory.
-.It Cm leap Ar file
-Specifies the location of the optional leapsecond file.
-This overrides the link
-.Pa ntpkey_leap
-in the keys directory.
-.It Cm mvpar Ar file
-Specifies the location of the optional MV parameters file.
-This
-overrides the link
-.Pa ntpkey_mv_ Ns Ar hostname
-in the keys directory.
-.It Cm pw Ar password
-Specifies the password to decrypt files containing private keys and
-identity parameters.
-This is required only if these files have been
-encrypted.
-.It Cm randfile Ar file
-Specifies the location of the random seed file used by the OpenSSL
-library.
-The defaults are described in the main text above.
-.It Cm sign Ar file
-Specifies the location of the optional sign key file.
-This overrides
-the link
-.Pa ntpkey_sign_ Ns Ar hostname
-in the keys directory.
-If this file is
-not found, the host key is also the sign key.
-.El
-.It Ic keys Ar keyfile
-Specifies the complete path and location of the MD5 key file
-containing the keys and key identifiers used by
-.Xr ntpd 1ntpdmdoc ,
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-when operating with symmetric key cryptography.
-This is the same operation as the
-.Fl k
-command line option.
-.It Ic keysdir Ar path
-This command specifies the default directory path for
-cryptographic keys, parameters and certificates.
-The default is
-.Pa /usr/local/etc/ .
-.It Ic requestkey Ar key
-Specifies the key identifier to use with the
-.Xr ntpdc 1ntpdcmdoc
-utility program, which uses a
-proprietary protocol specific to this implementation of
-.Xr ntpd 1ntpdmdoc .
-The
-.Ar key
-argument is a key identifier
-for the trusted key, where the value can be in the range 1 to
-65,534, inclusive.
-.It Ic revoke Ar logsec
-Specifies the interval between re-randomization of certain
-cryptographic values used by the Autokey scheme, as a power of 2 in
-seconds.
-These values need to be updated frequently in order to
-deflect brute-force attacks on the algorithms of the scheme;
-however, updating some values is a relatively expensive operation.
-The default interval is 16 (65,536 s or about 18 hours).
-For poll
-intervals above the specified interval, the values will be updated
-for every message sent.
-.It Ic trustedkey Ar key ...
-Specifies the key identifiers which are trusted for the
-purposes of authenticating peers with symmetric key cryptography,
-as well as keys used by the
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-programs.
-The authentication procedures require that both the local
-and remote servers share the same key and key identifier for this
-purpose, although different keys can be used with different
-servers.
-The
-.Ar key
-arguments are 32-bit unsigned
-integers with values from 1 to 65,534.
-.El
-.Ss Error Codes
-The following error codes are reported via the NTP control
-and monitoring protocol trap mechanism.
-.Bl -tag -width indent
-.It 101
-.Pq bad field format or length
-The packet has invalid version, length or format.
-.It 102
-.Pq bad timestamp
-The packet timestamp is the same or older than the most recent received.
-This could be due to a replay or a server clock time step.
-.It 103
-.Pq bad filestamp
-The packet filestamp is the same or older than the most recent received.
-This could be due to a replay or a key file generation error.
-.It 104
-.Pq bad or missing public key
-The public key is missing, has incorrect format or is an unsupported type.
-.It 105
-.Pq unsupported digest type
-The server requires an unsupported digest/signature scheme.
-.It 106
-.Pq mismatched digest types
-Not used.
-.It 107
-.Pq bad signature length
-The signature length does not match the current public key.
-.It 108
-.Pq signature not verified
-The message fails the signature check.
-It could be bogus or signed by a
-different private key.
-.It 109
-.Pq certificate not verified
-The certificate is invalid or signed with the wrong key.
-.It 110
-.Pq certificate not verified
-The certificate is not yet valid or has expired or the signature could not
-be verified.
-.It 111
-.Pq bad or missing cookie
-The cookie is missing, corrupted or bogus.
-.It 112
-.Pq bad or missing leapseconds table
-The leapseconds table is missing, corrupted or bogus.
-.It 113
-.Pq bad or missing certificate
-The certificate is missing, corrupted or bogus.
-.It 114
-.Pq bad or missing identity
-The identity key is missing, corrupt or bogus.
-.El
-.Sh Monitoring Support
-.Xr ntpd 1ntpdmdoc
-includes a comprehensive monitoring facility suitable
-for continuous, long term recording of server and client
-timekeeping performance.
-See the
-.Ic statistics
-command below
-for a listing and example of each type of statistics currently
-supported.
-Statistic files are managed using file generation sets
-and scripts in the
-.Pa ./scripts
-directory of this distribution.
-Using
-these facilities and
-.Ux
-.Xr cron 8
-jobs, the data can be
-automatically summarized and archived for retrospective analysis.
-.Ss Monitoring Commands
-.Bl -tag -width indent
-.It Ic statistics Ar name ...
-Enables writing of statistics records.
-Currently, four kinds of
-.Ar name
-statistics are supported.
-.Bl -tag -width indent
-.It Cm clockstats
-Enables recording of clock driver statistics information.
-Each update
-received from a clock driver appends a line of the following form to
-the file generation set named
-.Cm clockstats :
-.Bd -literal
-49213 525.624 127.127.4.1 93 226 00:08:29.606 D
-.Ed
-.Pp
-The first two fields show the date (Modified Julian Day) and time
-(seconds and fraction past UTC midnight).
-The next field shows the
-clock address in dotted-quad notation.
-The final field shows the last
-timecode received from the clock in decoded ASCII format, where
-meaningful.
-In some clock drivers a good deal of additional information
-can be gathered and displayed as well.
-See information specific to each
-clock for further details.
-.It Cm cryptostats
-This option requires the OpenSSL cryptographic software library.
-It
-enables recording of cryptographic public key protocol information.
-Each message received by the protocol module appends a line of the
-following form to the file generation set named
-.Cm cryptostats :
-.Bd -literal
-49213 525.624 127.127.4.1 message
-.Ed
-.Pp
-The first two fields show the date (Modified Julian Day) and time
-(seconds and fraction past UTC midnight).
-The next field shows the peer
-address in dotted-quad notation, The final message field includes the
-message type and certain ancillary information.
-See the
-.Sx Authentication Options
-section for further information.
-.It Cm loopstats
-Enables recording of loop filter statistics information.
-Each
-update of the local clock outputs a line of the following form to
-the file generation set named
-.Cm loopstats :
-.Bd -literal
-50935 75440.031 0.000006019 13.778190 0.000351733 0.0133806
-.Ed
-.Pp
-The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight).
-The next five fields
-show time offset (seconds), frequency offset (parts per million -
-PPM), RMS jitter (seconds), Allan deviation (PPM) and clock
-discipline time constant.
-.It Cm peerstats
-Enables recording of peer statistics information.
-This includes
-statistics records of all peers of a NTP server and of special
-signals, where present and configured.
-Each valid update appends a
-line of the following form to the current element of a file
-generation set named
-.Cm peerstats :
-.Bd -literal
-48773 10847.650 127.127.4.1 9714 -0.001605376 0.000000000 0.001424877 0.000958674
-.Ed
-.Pp
-The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight).
-The next two fields
-show the peer address in dotted-quad notation and status,
-respectively.
-The status field is encoded in hex in the format
-described in Appendix A of the NTP specification RFC 1305.
-The final four fields show the offset,
-delay, dispersion and RMS jitter, all in seconds.
-.It Cm rawstats
-Enables recording of raw-timestamp statistics information.
-This
-includes statistics records of all peers of a NTP server and of
-special signals, where present and configured.
-Each NTP message
-received from a peer or clock driver appends a line of the
-following form to the file generation set named
-.Cm rawstats :
-.Bd -literal
-50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 3102453281.58622800031 02453332.540806000 3102453332.541458000
-.Ed
-.Pp
-The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight).
-The next two fields
-show the remote peer or clock address followed by the local address
-in dotted-quad notation.
-The final four fields show the originate,
-receive, transmit and final NTP timestamps in order.
-The timestamp
-values are as received and before processing by the various data
-smoothing and mitigation algorithms.
-.It Cm sysstats
-Enables recording of ntpd statistics counters on a periodic basis.
-Each
-hour a line of the following form is appended to the file generation
-set named
-.Cm sysstats :
-.Bd -literal
-50928 2132.543 36000 81965 0 9546 56 71793 512 540 10 147
-.Ed
-.Pp
-The first two fields show the date (Modified Julian Day) and time
-(seconds and fraction past UTC midnight).
-The remaining ten fields show
-the statistics counter values accumulated since the last generated
-line.
-.Bl -tag -width indent
-.It Time since restart Cm 36000
-Time in hours since the system was last rebooted.
-.It Packets received Cm 81965
-Total number of packets received.
-.It Packets processed Cm 0
-Number of packets received in response to previous packets sent
-.It Current version Cm 9546
-Number of packets matching the current NTP version.
-.It Previous version Cm 56
-Number of packets matching the previous NTP version.
-.It Bad version Cm 71793
-Number of packets matching neither NTP version.
-.It Access denied Cm 512
-Number of packets denied access for any reason.
-.It Bad length or format Cm 540
-Number of packets with invalid length, format or port number.
-.It Bad authentication Cm 10
-Number of packets not verified as authentic.
-.It Rate exceeded Cm 147
-Number of packets discarded due to rate limitation.
-.El
-.It Cm statsdir Ar directory_path
-Indicates the full path of a directory where statistics files
-should be created (see below).
-This keyword allows
-the (otherwise constant)
-.Cm filegen
-filename prefix to be modified for file generation sets, which
-is useful for handling statistics logs.
-.It Cm filegen Ar name Xo
-.Op Cm file Ar filename
-.Op Cm type Ar typename
-.Op Cm link | nolink
-.Op Cm enable | disable
-.Xc
-Configures setting of generation file set name.
-Generation
-file sets provide a means for handling files that are
-continuously growing during the lifetime of a server.
-Server statistics are a typical example for such files.
-Generation file sets provide access to a set of files used
-to store the actual data.
-At any time at most one element
-of the set is being written to.
-The type given specifies
-when and how data will be directed to a new element of the set.
-This way, information stored in elements of a file set
-that are currently unused are available for administrational
-operations without the risk of disturbing the operation of ntpd.
-(Most important: they can be removed to free space for new data
-produced.)
-.Pp
-Note that this command can be sent from the
-.Xr ntpdc 1ntpdcmdoc
-program running at a remote location.
-.Bl -tag -width indent
-.It Cm name
-This is the type of the statistics records, as shown in the
-.Cm statistics
-command.
-.It Cm file Ar filename
-This is the file name for the statistics records.
-Filenames of set
-members are built from three concatenated elements
-.Ar Cm prefix ,
-.Ar Cm filename
-and
-.Ar Cm suffix :
-.Bl -tag -width indent
-.It Cm prefix
-This is a constant filename path.
-It is not subject to
-modifications via the
-.Ar filegen
-option.
-It is defined by the
-server, usually specified as a compile-time constant.
-It may,
-however, be configurable for individual file generation sets
-via other commands.
-For example, the prefix used with
-.Ar loopstats
-and
-.Ar peerstats
-generation can be configured using the
-.Ar statsdir
-option explained above.
-.It Cm filename
-This string is directly concatenated to the prefix mentioned
-above (no intervening
-.Ql / ) .
-This can be modified using
-the file argument to the
-.Ar filegen
-statement.
-No
-.Pa ..
-elements are
-allowed in this component to prevent filenames referring to
-parts outside the filesystem hierarchy denoted by
-.Ar prefix .
-.It Cm suffix
-This part is reflects individual elements of a file set.
-It is
-generated according to the type of a file set.
-.El
-.It Cm type Ar typename
-A file generation set is characterized by its type.
-The following
-types are supported:
-.Bl -tag -width indent
-.It Cm none
-The file set is actually a single plain file.
-.It Cm pid
-One element of file set is used per incarnation of a ntpd
-server.
-This type does not perform any changes to file set
-members during runtime, however it provides an easy way of
-separating files belonging to different
-.Xr ntpd 1ntpdmdoc
-server incarnations.
-The set member filename is built by appending a
-.Ql \&.
-to concatenated
-.Ar prefix
-and
-.Ar filename
-strings, and
-appending the decimal representation of the process ID of the
-.Xr ntpd 1ntpdmdoc
-server process.
-.It Cm day
-One file generation set element is created per day.
-A day is
-defined as the period between 00:00 and 24:00 UTC.
-The file set
-member suffix consists of a
-.Ql \&.
-and a day specification in
-the form
-.Cm YYYYMMdd .
-.Cm YYYY
-is a 4-digit year number (e.g., 1992).
-.Cm MM
-is a two digit month number.
-.Cm dd
-is a two digit day number.
-Thus, all information written at 10 December 1992 would end up
-in a file named
-.Ar prefix
-.Ar filename Ns .19921210 .
-.It Cm week
-Any file set member contains data related to a certain week of
-a year.
-The term week is defined by computing day-of-year
-modulo 7.
-Elements of such a file generation set are
-distinguished by appending the following suffix to the file set
-filename base: A dot, a 4-digit year number, the letter
-.Cm W ,
-and a 2-digit week number.
-For example, information from January,
-10th 1992 would end up in a file with suffix
-.No . Ns Ar 1992W1 .
-.It Cm month
-One generation file set element is generated per month.
-The
-file name suffix consists of a dot, a 4-digit year number, and
-a 2-digit month.
-.It Cm year
-One generation file element is generated per year.
-The filename
-suffix consists of a dot and a 4 digit year number.
-.It Cm age
-This type of file generation sets changes to a new element of
-the file set every 24 hours of server operation.
-The filename
-suffix consists of a dot, the letter
-.Cm a ,
-and an 8-digit number.
-This number is taken to be the number of seconds the server is
-running at the start of the corresponding 24-hour period.
-Information is only written to a file generation by specifying
-.Cm enable ;
-output is prevented by specifying
-.Cm disable .
-.El
-.It Cm link | nolink
-It is convenient to be able to access the current element of a file
-generation set by a fixed name.
-This feature is enabled by
-specifying
-.Cm link
-and disabled using
-.Cm nolink .
-If link is specified, a
-hard link from the current file set element to a file without
-suffix is created.
-When there is already a file with this name and
-the number of links of this file is one, it is renamed appending a
-dot, the letter
-.Cm C ,
-and the pid of the ntpd server process.
-When the
-number of links is greater than one, the file is unlinked.
-This
-allows the current file to be accessed by a constant name.
-.It Cm enable \&| Cm disable
-Enables or disables the recording function.
-.El
-.El
-.El
-.Sh Access Control Support
-The
-.Xr ntpd 1ntpdmdoc
-daemon implements a general purpose address/mask based restriction
-list.
-The list contains address/match entries sorted first
-by increasing address values and and then by increasing mask values.
-A match occurs when the bitwise AND of the mask and the packet
-source address is equal to the bitwise AND of the mask and
-address in the list.
-The list is searched in order with the
-last match found defining the restriction flags associated
-with the entry.
-Additional information and examples can be found in the
-.Qq Notes on Configuring NTP and Setting up a NTP Subnet
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.Pp
-The restriction facility was implemented in conformance
-with the access policies for the original NSFnet backbone
-time servers.
-Later the facility was expanded to deflect
-cryptographic and clogging attacks.
-While this facility may
-be useful for keeping unwanted or broken or malicious clients
-from congesting innocent servers, it should not be considered
-an alternative to the NTP authentication facilities.
-Source address based restrictions are easily circumvented
-by a determined cracker.
-.Pp
-Clients can be denied service because they are explicitly
-included in the restrict list created by the restrict command
-or implicitly as the result of cryptographic or rate limit
-violations.
-Cryptographic violations include certificate
-or identity verification failure; rate limit violations generally
-result from defective NTP implementations that send packets
-at abusive rates.
-Some violations cause denied service
-only for the offending packet, others cause denied service
-for a timed period and others cause the denied service for
-an indefinate period.
-When a client or network is denied access
-for an indefinate period, the only way at present to remove
-the restrictions is by restarting the server.
-.Ss The Kiss-of-Death Packet
-Ordinarily, packets denied service are simply dropped with no
-further action except incrementing statistics counters.
-Sometimes a
-more proactive response is needed, such as a server message that
-explicitly requests the client to stop sending and leave a message
-for the system operator.
-A special packet format has been created
-for this purpose called the "kiss-of-death" (KoD) packet.
-KoD packets have the leap bits set unsynchronized and stratum set
-to zero and the reference identifier field set to a four-byte
-ASCII code.
-If the
-.Cm noserve
-or
-.Cm notrust
-flag of the matching restrict list entry is set,
-the code is "DENY"; if the
-.Cm limited
-flag is set and the rate limit
-is exceeded, the code is "RATE".
-Finally, if a cryptographic violation occurs, the code is "CRYP".
-.Pp
-A client receiving a KoD performs a set of sanity checks to
-minimize security exposure, then updates the stratum and
-reference identifier peer variables, sets the access
-denied (TEST4) bit in the peer flash variable and sends
-a message to the log.
-As long as the TEST4 bit is set,
-the client will send no further packets to the server.
-The only way at present to recover from this condition is
-to restart the protocol at both the client and server.
-This
-happens automatically at the client when the association times out.
-It will happen at the server only if the server operator cooperates.
-.Ss Access Control Commands
-.Bl -tag -width indent
-.It Xo Ic discard
-.Op Cm average Ar avg
-.Op Cm minimum Ar min
-.Op Cm monitor Ar prob
-.Xc
-Set the parameters of the
-.Cm limited
-facility which protects the server from
-client abuse.
-The
-.Cm average
-subcommand specifies the minimum average packet
-spacing, while the
-.Cm minimum
-subcommand specifies the minimum packet spacing.
-Packets that violate these minima are discarded
-and a kiss-o'-death packet returned if enabled.
-The default
-minimum average and minimum are 5 and 2, respectively.
-The monitor subcommand specifies the probability of discard
-for packets that overflow the rate-control window.
-.It Xo Ic restrict address
-.Op Cm mask Ar mask
-.Op Ar flag ...
-.Xc
-The
-.Ar address
-argument expressed in
-dotted-quad form is the address of a host or network.
-Alternatively, the
-.Ar address
-argument can be a valid host DNS name.
-The
-.Ar mask
-argument expressed in dotted-quad form defaults to
-.Cm 255.255.255.255 ,
-meaning that the
-.Ar address
-is treated as the address of an individual host.
-A default entry (address
-.Cm 0.0.0.0 ,
-mask
-.Cm 0.0.0.0 )
-is always included and is always the first entry in the list.
-Note that text string
-.Cm default ,
-with no mask option, may
-be used to indicate the default entry.
-In the current implementation,
-.Cm flag
-always
-restricts access, i.e., an entry with no flags indicates that free
-access to the server is to be given.
-The flags are not orthogonal,
-in that more restrictive flags will often make less restrictive
-ones redundant.
-The flags can generally be classed into two
-categories, those which restrict time service and those which
-restrict informational queries and attempts to do run-time
-reconfiguration of the server.
-One or more of the following flags
-may be specified:
-.Bl -tag -width indent
-.It Cm ignore
-Deny packets of all kinds, including
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-queries.
-.It Cm kod
-If this flag is set when an access violation occurs, a kiss-o'-death
-(KoD) packet is sent.
-KoD packets are rate limited to no more than one
-per second.
-If another KoD packet occurs within one second after the
-last one, the packet is dropped.
-.It Cm limited
-Deny service if the packet spacing violates the lower limits specified
-in the discard command.
-A history of clients is kept using the
-monitoring capability of
-.Xr ntpd 1ntpdmdoc .
-Thus, monitoring is always active as
-long as there is a restriction entry with the
-.Cm limited
-flag.
-.It Cm lowpriotrap
-Declare traps set by matching hosts to be low priority.
-The
-number of traps a server can maintain is limited (the current limit
-is 3).
-Traps are usually assigned on a first come, first served
-basis, with later trap requestors being denied service.
-This flag
-modifies the assignment algorithm by allowing low priority traps to
-be overridden by later requests for normal priority traps.
-.It Cm nomodify
-Deny
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-queries which attempt to modify the state of the
-server (i.e., run time reconfiguration).
-Queries which return
-information are permitted.
-.It Cm noquery
-Deny
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-queries.
-Time service is not affected.
-.It Cm nopeer
-Deny packets which would result in mobilizing a new association.
-This
-includes broadcast and symmetric active packets when a configured
-association does not exist.
-.It Cm noserve
-Deny all packets except
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-queries.
-.It Cm notrap
-Decline to provide mode 6 control message trap service to matching
-hosts.
-The trap service is a subsystem of the ntpdq control message
-protocol which is intended for use by remote event logging programs.
-.It Cm notrust
-Deny service unless the packet is cryptographically authenticated.
-.It Cm ntpport
-This is actually a match algorithm modifier, rather than a
-restriction flag.
-Its presence causes the restriction entry to be
-matched only if the source port in the packet is the standard NTP
-UDP port (123).
-Both
-.Cm ntpport
-and
-.Cm non-ntpport
-may
-be specified.
-The
-.Cm ntpport
-is considered more specific and
-is sorted later in the list.
-.It Cm version
-Deny packets that do not match the current NTP version.
-.El
-.Pp
-Default restriction list entries with the flags ignore, interface,
-ntpport, for each of the local host's interface addresses are
-inserted into the table at startup to prevent the server
-from attempting to synchronize to its own time.
-A default entry is also always present, though if it is
-otherwise unconfigured; no flags are associated
-with the default entry (i.e., everything besides your own
-NTP server is unrestricted).
-.El
-.Sh Automatic NTP Configuration Options
-.Ss Manycasting
-Manycasting is a automatic discovery and configuration paradigm
-new to NTPv4.
-It is intended as a means for a multicast client
-to troll the nearby network neighborhood to find cooperating
-manycast servers, validate them using cryptographic means
-and evaluate their time values with respect to other servers
-that might be lurking in the vicinity.
-The intended result is that each manycast client mobilizes
-client associations with some number of the "best"
-of the nearby manycast servers, yet automatically reconfigures
-to sustain this number of servers should one or another fail.
-.Pp
-Note that the manycasting paradigm does not coincide
-with the anycast paradigm described in RFC-1546,
-which is designed to find a single server from a clique
-of servers providing the same service.
-The manycast paradigm is designed to find a plurality
-of redundant servers satisfying defined optimality criteria.
-.Pp
-Manycasting can be used with either symmetric key
-or public key cryptography.
-The public key infrastructure (PKI)
-offers the best protection against compromised keys
-and is generally considered stronger, at least with relatively
-large key sizes.
-It is implemented using the Autokey protocol and
-the OpenSSL cryptographic library available from
-.Li http://www.openssl.org/ .
-The library can also be used with other NTPv4 modes
-as well and is highly recommended, especially for broadcast modes.
-.Pp
-A persistent manycast client association is configured
-using the manycastclient command, which is similar to the
-server command but with a multicast (IPv4 class
-.Cm D
-or IPv6 prefix
-.Cm FF )
-group address.
-The IANA has designated IPv4 address 224.1.1.1
-and IPv6 address FF05::101 (site local) for NTP.
-When more servers are needed, it broadcasts manycast
-client messages to this address at the minimum feasible rate
-and minimum feasible time-to-live (TTL) hops, depending
-on how many servers have already been found.
-There can be as many manycast client associations
-as different group address, each one serving as a template
-for a future ephemeral unicast client/server association.
-.Pp
-Manycast servers configured with the
-.Ic manycastserver
-command listen on the specified group address for manycast
-client messages.
-Note the distinction between manycast client,
-which actively broadcasts messages, and manycast server,
-which passively responds to them.
-If a manycast server is
-in scope of the current TTL and is itself synchronized
-to a valid source and operating at a stratum level equal
-to or lower than the manycast client, it replies to the
-manycast client message with an ordinary unicast server message.
-.Pp
-The manycast client receiving this message mobilizes
-an ephemeral client/server association according to the
-matching manycast client template, but only if cryptographically
-authenticated and the server stratum is less than or equal
-to the client stratum.
-Authentication is explicitly required
-and either symmetric key or public key (Autokey) can be used.
-Then, the client polls the server at its unicast address
-in burst mode in order to reliably set the host clock
-and validate the source.
-This normally results
-in a volley of eight client/server at 2-s intervals
-during which both the synchronization and cryptographic
-protocols run concurrently.
-Following the volley,
-the client runs the NTP intersection and clustering
-algorithms, which act to discard all but the "best"
-associations according to stratum and synchronization
-distance.
-The surviving associations then continue
-in ordinary client/server mode.
-.Pp
-The manycast client polling strategy is designed to reduce
-as much as possible the volume of manycast client messages
-and the effects of implosion due to near-simultaneous
-arrival of manycast server messages.
-The strategy is determined by the
-.Ic manycastclient ,
-.Ic tos
-and
-.Ic ttl
-configuration commands.
-The manycast poll interval is
-normally eight times the system poll interval,
-which starts out at the
-.Cm minpoll
-value specified in the
-.Ic manycastclient ,
-command and, under normal circumstances, increments to the
-.Cm maxpolll
-value specified in this command.
-Initially, the TTL is
-set at the minimum hops specified by the ttl command.
-At each retransmission the TTL is increased until reaching
-the maximum hops specified by this command or a sufficient
-number client associations have been found.
-Further retransmissions use the same TTL.
-.Pp
-The quality and reliability of the suite of associations
-discovered by the manycast client is determined by the NTP
-mitigation algorithms and the
-.Cm minclock
-and
-.Cm minsane
-values specified in the
-.Ic tos
-configuration command.
-At least
-.Cm minsane
-candidate servers must be available and the mitigation
-algorithms produce at least
-.Cm minclock
-survivors in order to synchronize the clock.
-Byzantine agreement principles require at least four
-candidates in order to correctly discard a single falseticker.
-For legacy purposes,
-.Cm minsane
-defaults to 1 and
-.Cm minclock
-defaults to 3.
-For manycast service
-.Cm minsane
-should be explicitly set to 4, assuming at least that
-number of servers are available.
-.Pp
-If at least
-.Cm minclock
-servers are found, the manycast poll interval is immediately
-set to eight times
-.Cm maxpoll .
-If less than
-.Cm minclock
-servers are found when the TTL has reached the maximum hops,
-the manycast poll interval is doubled.
-For each transmission
-after that, the poll interval is doubled again until
-reaching the maximum of eight times
-.Cm maxpoll .
-Further transmissions use the same poll interval and
-TTL values.
-Note that while all this is going on,
-each client/server association found is operating normally
-it the system poll interval.
-.Pp
-Administratively scoped multicast boundaries are normally
-specified by the network router configuration and,
-in the case of IPv6, the link/site scope prefix.
-By default, the increment for TTL hops is 32 starting
-from 31; however, the
-.Ic ttl
-configuration command can be
-used to modify the values to match the scope rules.
-.Pp
-It is often useful to narrow the range of acceptable
-servers which can be found by manycast client associations.
-Because manycast servers respond only when the client
-stratum is equal to or greater than the server stratum,
-primary (stratum 1) servers fill find only primary servers
-in TTL range, which is probably the most common objective.
-However, unless configured otherwise, all manycast clients
-in TTL range will eventually find all primary servers
-in TTL range, which is probably not the most common
-objective in large networks.
-The
-.Ic tos
-command can be used to modify this behavior.
-Servers with stratum below
-.Cm floor
-or above
-.Cm ceiling
-specified in the
-.Ic tos
-command are strongly discouraged during the selection
-process; however, these servers may be temporally
-accepted if the number of servers within TTL range is
-less than
-.Cm minclock .
-.Pp
-The above actions occur for each manycast client message,
-which repeats at the designated poll interval.
-However, once the ephemeral client association is mobilized,
-subsequent manycast server replies are discarded,
-since that would result in a duplicate association.
-If during a poll interval the number of client associations
-falls below
-.Cm minclock ,
-all manycast client prototype associations are reset
-to the initial poll interval and TTL hops and operation
-resumes from the beginning.
-It is important to avoid
-frequent manycast client messages, since each one requires
-all manycast servers in TTL range to respond.
-The result could well be an implosion, either minor or major,
-depending on the number of servers in range.
-The recommended value for
-.Cm maxpoll
-is 12 (4,096 s).
-.Pp
-It is possible and frequently useful to configure a host
-as both manycast client and manycast server.
-A number of hosts configured this way and sharing a common
-group address will automatically organize themselves
-in an optimum configuration based on stratum and
-synchronization distance.
-For example, consider an NTP
-subnet of two primary servers and a hundred or more
-dependent clients.
-With two exceptions, all servers
-and clients have identical configuration files including both
-.Ic multicastclient
-and
-.Ic multicastserver
-commands using, for instance, multicast group address
-239.1.1.1.
-The only exception is that each primary server
-configuration file must include commands for the primary
-reference source such as a GPS receiver.
-.Pp
-The remaining configuration files for all secondary
-servers and clients have the same contents, except for the
-.Ic tos
-command, which is specific for each stratum level.
-For stratum 1 and stratum 2 servers, that command is
-not necessary.
-For stratum 3 and above servers the
-.Cm floor
-value is set to the intended stratum number.
-Thus, all stratum 3 configuration files are identical,
-all stratum 4 files are identical and so forth.
-.Pp
-Once operations have stabilized in this scenario,
-the primary servers will find the primary reference source
-and each other, since they both operate at the same
-stratum (1), but not with any secondary server or client,
-since these operate at a higher stratum.
-The secondary
-servers will find the servers at the same stratum level.
-If one of the primary servers loses its GPS receiver,
-it will continue to operate as a client and other clients
-will time out the corresponding association and
-re-associate accordingly.
-.Pp
-Some administrators prefer to avoid running
-.Xr ntpd 1ntpdmdoc
-continuously and run either
-.Xr ntpdate 8
-or
-.Xr ntpd 1ntpdmdoc
-.Fl q
-as a cron job.
-In either case the servers must be
-configured in advance and the program fails if none are
-available when the cron job runs.
-A really slick
-application of manycast is with
-.Xr ntpd 1ntpdmdoc
-.Fl q .
-The program wakes up, scans the local landscape looking
-for the usual suspects, selects the best from among
-the rascals, sets the clock and then departs.
-Servers do not have to be configured in advance and
-all clients throughout the network can have the same
-configuration file.
-.Ss Manycast Interactions with Autokey
-Each time a manycast client sends a client mode packet
-to a multicast group address, all manycast servers
-in scope generate a reply including the host name
-and status word.
-The manycast clients then run
-the Autokey protocol, which collects and verifies
-all certificates involved.
-Following the burst interval
-all but three survivors are cast off,
-but the certificates remain in the local cache.
-It often happens that several complete signing trails
-from the client to the primary servers are collected in this way.
-.Pp
-About once an hour or less often if the poll interval
-exceeds this, the client regenerates the Autokey key list.
-This is in general transparent in client/server mode.
-However, about once per day the server private value
-used to generate cookies is refreshed along with all
-manycast client associations.
-In this case all
-cryptographic values including certificates is refreshed.
-If a new certificate has been generated since
-the last refresh epoch, it will automatically revoke
-all prior certificates that happen to be in the
-certificate cache.
-At the same time, the manycast
-scheme starts all over from the beginning and
-the expanding ring shrinks to the minimum and increments
-from there while collecting all servers in scope.
-.Ss Manycast Options
-.Bl -tag -width indent
-.It Xo Ic tos
-.Oo
-.Cm ceiling Ar ceiling |
-.Cm cohort { 0 | 1 } |
-.Cm floor Ar floor |
-.Cm minclock Ar minclock |
-.Cm minsane Ar minsane
-.Oc
-.Xc
-This command affects the clock selection and clustering
-algorithms.
-It can be used to select the quality and
-quantity of peers used to synchronize the system clock
-and is most useful in manycast mode.
-The variables operate
-as follows:
-.Bl -tag -width indent
-.It Cm ceiling Ar ceiling
-Peers with strata above
-.Cm ceiling
-will be discarded if there are at least
-.Cm minclock
-peers remaining.
-This value defaults to 15, but can be changed
-to any number from 1 to 15.
-.It Cm cohort Bro 0 | 1 Brc
-This is a binary flag which enables (0) or disables (1)
-manycast server replies to manycast clients with the same
-stratum level.
-This is useful to reduce implosions where
-large numbers of clients with the same stratum level
-are present.
-The default is to enable these replies.
-.It Cm floor Ar floor
-Peers with strata below
-.Cm floor
-will be discarded if there are at least
-.Cm minclock
-peers remaining.
-This value defaults to 1, but can be changed
-to any number from 1 to 15.
-.It Cm minclock Ar minclock
-The clustering algorithm repeatedly casts out outlyer
-associations until no more than
-.Cm minclock
-associations remain.
-This value defaults to 3,
-but can be changed to any number from 1 to the number of
-configured sources.
-.It Cm minsane Ar minsane
-This is the minimum number of candidates available
-to the clock selection algorithm in order to produce
-one or more truechimers for the clustering algorithm.
-If fewer than this number are available, the clock is
-undisciplined and allowed to run free.
-The default is 1
-for legacy purposes.
-However, according to principles of
-Byzantine agreement,
-.Cm minsane
-should be at least 4 in order to detect and discard
-a single falseticker.
-.El
-.It Cm ttl Ar hop ...
-This command specifies a list of TTL values in increasing
-order, up to 8 values can be specified.
-In manycast mode these values are used in turn
-in an expanding-ring search.
-The default is eight
-multiples of 32 starting at 31.
-.El
-.Sh Reference Clock Support
-The NTP Version 4 daemon supports some three dozen different radio,
-satellite and modem reference clocks plus a special pseudo-clock
-used for backup or when no other clock source is available.
-Detailed descriptions of individual device drivers and options can
-be found in the
-.Qq Reference Clock Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-Additional information can be found in the pages linked
-there, including the
-.Qq Debugging Hints for Reference Clock Drivers
-and
-.Qq How To Write a Reference Clock Driver
-pages
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-In addition, support for a PPS
-signal is available as described in the
-.Qq Pulse-per-second (PPS) Signal Interfacing
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-Many
-drivers support special line discipline/streams modules which can
-significantly improve the accuracy using the driver.
-These are
-described in the
-.Qq Line Disciplines and Streams Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.Pp
-A reference clock will generally (though not always) be a radio
-timecode receiver which is synchronized to a source of standard
-time such as the services offered by the NRC in Canada and NIST and
-USNO in the US.
-The interface between the computer and the timecode
-receiver is device dependent, but is usually a serial port.
-A
-device driver specific to each reference clock must be selected and
-compiled in the distribution; however, most common radio, satellite
-and modem clocks are included by default.
-Note that an attempt to
-configure a reference clock when the driver has not been compiled
-or the hardware port has not been appropriately configured results
-in a scalding remark to the system log file, but is otherwise non
-hazardous.
-.Pp
-For the purposes of configuration,
-.Xr ntpd 1ntpdmdoc
-treats
-reference clocks in a manner analogous to normal NTP peers as much
-as possible.
-Reference clocks are identified by a syntactically
-correct but invalid IP address, in order to distinguish them from
-normal NTP peers.
-Reference clock addresses are of the form
-.Sm off
-.Li 127.127. Ar t . Ar u ,
-.Sm on
-where
-.Ar t
-is an integer
-denoting the clock type and
-.Ar u
-indicates the unit
-number in the range 0-3.
-While it may seem overkill, it is in fact
-sometimes useful to configure multiple reference clocks of the same
-type, in which case the unit numbers must be unique.
-.Pp
-The
-.Ic server
-command is used to configure a reference
-clock, where the
-.Ar address
-argument in that command
-is the clock address.
-The
-.Cm key ,
-.Cm version
-and
-.Cm ttl
-options are not used for reference clock support.
-The
-.Cm mode
-option is added for reference clock support, as
-described below.
-The
-.Cm prefer
-option can be useful to
-persuade the server to cherish a reference clock with somewhat more
-enthusiasm than other reference clocks or peers.
-Further
-information on this option can be found in the
-.Qq Mitigation Rules and the prefer Keyword
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-page.
-The
-.Cm minpoll
-and
-.Cm maxpoll
-options have
-meaning only for selected clock drivers.
-See the individual clock
-driver document pages for additional information.
-.Pp
-The
-.Ic fudge
-command is used to provide additional
-information for individual clock drivers and normally follows
-immediately after the
-.Ic server
-command.
-The
-.Ar address
-argument specifies the clock address.
-The
-.Cm refid
-and
-.Cm stratum
-options can be used to
-override the defaults for the device.
-There are two optional
-device-dependent time offsets and four flags that can be included
-in the
-.Ic fudge
-command as well.
-.Pp
-The stratum number of a reference clock is by default zero.
-Since the
-.Xr ntpd 1ntpdmdoc
-daemon adds one to the stratum of each
-peer, a primary server ordinarily displays an external stratum of
-one.
-In order to provide engineered backups, it is often useful to
-specify the reference clock stratum as greater than zero.
-The
-.Cm stratum
-option is used for this purpose.
-Also, in cases
-involving both a reference clock and a pulse-per-second (PPS)
-discipline signal, it is useful to specify the reference clock
-identifier as other than the default, depending on the driver.
-The
-.Cm refid
-option is used for this purpose.
-Except where noted,
-these options apply to all clock drivers.
-.Ss Reference Clock Commands
-.Bl -tag -width indent
-.It Xo Ic server
-.Sm off
-.Li 127.127. Ar t . Ar u
-.Sm on
-.Op Cm prefer
-.Op Cm mode Ar int
-.Op Cm minpoll Ar int
-.Op Cm maxpoll Ar int
-.Xc
-This command can be used to configure reference clocks in
-special ways.
-The options are interpreted as follows:
-.Bl -tag -width indent
-.It Cm prefer
-Marks the reference clock as preferred.
-All other things being
-equal, this host will be chosen for synchronization among a set of
-correctly operating hosts.
-See the
-.Qq Mitigation Rules and the prefer Keyword
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-for further information.
-.It Cm mode Ar int
-Specifies a mode number which is interpreted in a
-device-specific fashion.
-For instance, it selects a dialing
-protocol in the ACTS driver and a device subtype in the
-parse
-drivers.
-.It Cm minpoll Ar int
-.It Cm maxpoll Ar int
-These options specify the minimum and maximum polling interval
-for reference clock messages, as a power of 2 in seconds
-For
-most directly connected reference clocks, both
-.Cm minpoll
-and
-.Cm maxpoll
-default to 6 (64 s).
-For modem reference clocks,
-.Cm minpoll
-defaults to 10 (17.1 m) and
-.Cm maxpoll
-defaults to 14 (4.5 h).
-The allowable range is 4 (16 s) to 17 (36.4 h) inclusive.
-.El
-.It Xo Ic fudge
-.Sm off
-.Li 127.127. Ar t . Ar u
-.Sm on
-.Op Cm time1 Ar sec
-.Op Cm time2 Ar sec
-.Op Cm stratum Ar int
-.Op Cm refid Ar string
-.Op Cm mode Ar int
-.Op Cm flag1 Cm 0 \&| Cm 1
-.Op Cm flag2 Cm 0 \&| Cm 1
-.Op Cm flag3 Cm 0 \&| Cm 1
-.Op Cm flag4 Cm 0 \&| Cm 1
-.Xc
-This command can be used to configure reference clocks in
-special ways.
-It must immediately follow the
-.Ic server
-command which configures the driver.
-Note that the same capability
-is possible at run time using the
-.Xr ntpdc 1ntpdcmdoc
-program.
-The options are interpreted as
-follows:
-.Bl -tag -width indent
-.It Cm time1 Ar sec
-Specifies a constant to be added to the time offset produced by
-the driver, a fixed-point decimal number in seconds.
-This is used
-as a calibration constant to adjust the nominal time offset of a
-particular clock to agree with an external standard, such as a
-precision PPS signal.
-It also provides a way to correct a
-systematic error or bias due to serial port or operating system
-latencies, different cable lengths or receiver internal delay.
-The
-specified offset is in addition to the propagation delay provided
-by other means, such as internal DIPswitches.
-Where a calibration
-for an individual system and driver is available, an approximate
-correction is noted in the driver documentation pages.
-Note: in order to facilitate calibration when more than one
-radio clock or PPS signal is supported, a special calibration
-feature is available.
-It takes the form of an argument to the
-.Ic enable
-command described in
-.Sx Miscellaneous Options
-page and operates as described in the
-.Qq Reference Clock Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.It Cm time2 Ar secs
-Specifies a fixed-point decimal number in seconds, which is
-interpreted in a driver-dependent way.
-See the descriptions of
-specific drivers in the
-.Qq Reference Clock Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.It Cm stratum Ar int
-Specifies the stratum number assigned to the driver, an integer
-between 0 and 15.
-This number overrides the default stratum number
-ordinarily assigned by the driver itself, usually zero.
-.It Cm refid Ar string
-Specifies an ASCII string of from one to four characters which
-defines the reference identifier used by the driver.
-This string
-overrides the default identifier ordinarily assigned by the driver
-itself.
-.It Cm mode Ar int
-Specifies a mode number which is interpreted in a
-device-specific fashion.
-For instance, it selects a dialing
-protocol in the ACTS driver and a device subtype in the
-parse
-drivers.
-.It Cm flag1 Cm 0 \&| Cm 1
-.It Cm flag2 Cm 0 \&| Cm 1
-.It Cm flag3 Cm 0 \&| Cm 1
-.It Cm flag4 Cm 0 \&| Cm 1
-These four flags are used for customizing the clock driver.
-The
-interpretation of these values, and whether they are used at all,
-is a function of the particular clock driver.
-However, by
-convention
-.Cm flag4
-is used to enable recording monitoring
-data to the
-.Cm clockstats
-file configured with the
-.Ic filegen
-command.
-Further information on the
-.Ic filegen
-command can be found in
-.Sx Monitoring Options .
-.El
-.El
-.Sh Miscellaneous Options
-.Bl -tag -width indent
-.It Ic broadcastdelay Ar seconds
-The broadcast and multicast modes require a special calibration
-to determine the network delay between the local and remote
-servers.
-Ordinarily, this is done automatically by the initial
-protocol exchanges between the client and server.
-In some cases,
-the calibration procedure may fail due to network or server access
-controls, for example.
-This command specifies the default delay to
-be used under these circumstances.
-Typically (for Ethernet), a
-number between 0.003 and 0.007 seconds is appropriate.
-The default
-when this command is not used is 0.004 seconds.
-.It Ic calldelay Ar delay
-This option controls the delay in seconds between the first and second
-packets sent in burst or iburst mode to allow additional time for a modem
-or ISDN call to complete.
-.It Ic driftfile Ar driftfile
-This command specifies the complete path and name of the file used to
-record the frequency of the local clock oscillator.
-This is the same
-operation as the
-.Fl f
-command line option.
-If the file exists, it is read at
-startup in order to set the initial frequency and then updated once per
-hour with the current frequency computed by the daemon.
-If the file name is
-specified, but the file itself does not exist, the starts with an initial
-frequency of zero and creates the file when writing it for the first time.
-If this command is not given, the daemon will always start with an initial
-frequency of zero.
-.Pp
-The file format consists of a single line containing a single
-floating point number, which records the frequency offset measured
-in parts-per-million (PPM).
-The file is updated by first writing
-the current drift value into a temporary file and then renaming
-this file to replace the old version.
-This implies that
-.Xr ntpd 1ntpdmdoc
-must have write permission for the directory the
-drift file is located in, and that file system links, symbolic or
-otherwise, should be avoided.
-.It Xo Ic enable
-.Oo
-.Cm auth | Cm bclient |
-.Cm calibrate | Cm kernel |
-.Cm monitor | Cm ntp |
-.Cm pps | Cm stats
-.Oc
-.Xc
-.It Xo Ic disable
-.Oo
-.Cm auth | Cm bclient |
-.Cm calibrate | Cm kernel |
-.Cm monitor | Cm ntp |
-.Cm pps | Cm stats
-.Oc
-.Xc
-Provides a way to enable or disable various server options.
-Flags not mentioned are unaffected.
-Note that all of these flags
-can be controlled remotely using the
-.Xr ntpdc 1ntpdcmdoc
-utility program.
-.Bl -tag -width indent
-.It Cm auth
-Enables the server to synchronize with unconfigured peers only if the
-peer has been correctly authenticated using either public key or
-private key cryptography.
-The default for this flag is
-.Ic enable .
-.It Cm bclient
-Enables the server to listen for a message from a broadcast or
-multicast server, as in the
-.Ic multicastclient
-command with default
-address.
-The default for this flag is
-.Ic disable .
-.It Cm calibrate
-Enables the calibrate feature for reference clocks.
-The default for
-this flag is
-.Ic disable .
-.It Cm kernel
-Enables the kernel time discipline, if available.
-The default for this
-flag is
-.Ic enable
-if support is available, otherwise
-.Ic disable .
-.It Cm monitor
-Enables the monitoring facility.
-See the
-.Xr ntpdc 1ntpdcmdoc
-program
-and the
-.Ic monlist
-command or further information.
-The
-default for this flag is
-.Ic enable .
-.It Cm ntp
-Enables time and frequency discipline.
-In effect, this switch opens and
-closes the feedback loop, which is useful for testing.
-The default for
-this flag is
-.Ic enable .
-.It Cm pps
-Enables the pulse-per-second (PPS) signal when frequency and time is
-disciplined by the precision time kernel modifications.
-See the
-.Qq A Kernel Model for Precision Timekeeping
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-page for further information.
-The default for this flag is
-.Ic disable .
-.It Cm stats
-Enables the statistics facility.
-See the
-.Sx Monitoring Options
-section for further information.
-The default for this flag is
-.Ic disable .
-.El
-.It Ic includefile Ar includefile
-This command allows additional configuration commands
-to be included from a separate file.
-Include files may
-be nested to a depth of five; upon reaching the end of any
-include file, command processing resumes in the previous
-configuration file.
-This option is useful for sites that run
-.Xr ntpd 1ntpdmdoc
-on multiple hosts, with (mostly) common options (e.g., a
-restriction list).
-.It Ic logconfig Ar configkeyword
-This command controls the amount and type of output written to
-the system
-.Xr syslog 3
-facility or the alternate
-.Ic logfile
-log file.
-By default, all output is turned on.
-All
-.Ar configkeyword
-keywords can be prefixed with
-.Ql = ,
-.Ql +
-and
-.Ql - ,
-where
-.Ql =
-sets the
-.Xr syslog 3
-priority mask,
-.Ql +
-adds and
-.Ql -
-removes
-messages.
-.Xr syslog 3
-messages can be controlled in four
-classes
-.Po
-.Cm clock ,
-.Cm peer ,
-.Cm sys
-and
-.Cm sync
-.Pc .
-Within these classes four types of messages can be
-controlled: informational messages
-.Po
-.Cm info
-.Pc ,
-event messages
-.Po
-.Cm events
-.Pc ,
-statistics messages
-.Po
-.Cm statistics
-.Pc
-and
-status messages
-.Po
-.Cm status
-.Pc .
-.Pp
-Configuration keywords are formed by concatenating the message class with
-the event class.
-The
-.Cm all
-prefix can be used instead of a message class.
-A
-message class may also be followed by the
-.Cm all
-keyword to enable/disable all
-messages of the respective message class.Thus, a minimal log configuration
-could look like this:
-.Bd -literal
-logconfig =syncstatus +sysevents
-.Ed
-.Pp
-This would just list the synchronizations state of
-.Xr ntpd 1ntpdmdoc
-and the major system events.
-For a simple reference server, the
-following minimum message configuration could be useful:
-.Bd -literal
-logconfig =syncall +clockall
-.Ed
-.Pp
-This configuration will list all clock information and
-synchronization information.
-All other events and messages about
-peers, system events and so on is suppressed.
-.It Ic logfile Ar logfile
-This command specifies the location of an alternate log file to
-be used instead of the default system
-.Xr syslog 3
-facility.
-This is the same operation as the -l command line option.
-.It Ic setvar Ar variable Op Cm default
-This command adds an additional system variable.
-These
-variables can be used to distribute additional information such as
-the access policy.
-If the variable of the form
-.Sm off
-.Va name = Ar value
-.Sm on
-is followed by the
-.Cm default
-keyword, the
-variable will be listed as part of the default system variables
-.Po
-.Xr ntpq 1ntpqmdoc
-.Ic rv
-command
-.Pc ) .
-These additional variables serve
-informational purposes only.
-They are not related to the protocol
-other that they can be listed.
-The known protocol variables will
-always override any variables defined via the
-.Ic setvar
-mechanism.
-There are three special variables that contain the names
-of all variable of the same group.
-The
-.Va sys_var_list
-holds
-the names of all system variables.
-The
-.Va peer_var_list
-holds
-the names of all peer variables and the
-.Va clock_var_list
-holds the names of the reference clock variables.
-.It Xo Ic tinker
-.Oo
-.Cm allan Ar allan |
-.Cm dispersion Ar dispersion |
-.Cm freq Ar freq |
-.Cm huffpuff Ar huffpuff |
-.Cm panic Ar panic |
-.Cm step Ar srep |
-.Cm stepout Ar stepout
-.Oc
-.Xc
-This command can be used to alter several system variables in
-very exceptional circumstances.
-It should occur in the
-configuration file before any other configuration options.
-The
-default values of these variables have been carefully optimized for
-a wide range of network speeds and reliability expectations.
-In
-general, they interact in intricate ways that are hard to predict
-and some combinations can result in some very nasty behavior.
-Very
-rarely is it necessary to change the default values; but, some
-folks cannot resist twisting the knobs anyway and this command is
-for them.
-Emphasis added: twisters are on their own and can expect
-no help from the support group.
-.Pp
-The variables operate as follows:
-.Bl -tag -width indent
-.It Cm allan Ar allan
-The argument becomes the new value for the minimum Allan
-intercept, which is a parameter of the PLL/FLL clock discipline
-algorithm.
-The value in log2 seconds defaults to 7 (1024 s), which is also the lower
-limit.
-.It Cm dispersion Ar dispersion
-The argument becomes the new value for the dispersion increase rate,
-normally .000015 s/s.
-.It Cm freq Ar freq
-The argument becomes the initial value of the frequency offset in
-parts-per-million.
-This overrides the value in the frequency file, if
-present, and avoids the initial training state if it is not.
-.It Cm huffpuff Ar huffpuff
-The argument becomes the new value for the experimental
-huff-n'-puff filter span, which determines the most recent interval
-the algorithm will search for a minimum delay.
-The lower limit is
-900 s (15 m), but a more reasonable value is 7200 (2 hours).
-There
-is no default, since the filter is not enabled unless this command
-is given.
-.It Cm panic Ar panic
-The argument is the panic threshold, normally 1000 s.
-If set to zero,
-the panic sanity check is disabled and a clock offset of any value will
-be accepted.
-.It Cm step Ar step
-The argument is the step threshold, which by default is 0.128 s.
-It can
-be set to any positive number in seconds.
-If set to zero, step
-adjustments will never occur.
-Note: The kernel time discipline is
-disabled if the step threshold is set to zero or greater than the
-default.
-.It Cm stepout Ar stepout
-The argument is the stepout timeout, which by default is 900 s.
-It can
-be set to any positive number in seconds.
-If set to zero, the stepout
-pulses will not be suppressed.
-.El
-.It Xo Ic trap Ar host_address
-.Op Cm port Ar port_number
-.Op Cm interface Ar interface_address
-.Xc
-This command configures a trap receiver at the given host
-address and port number for sending messages with the specified
-local interface address.
-If the port number is unspecified, a value
-of 18447 is used.
-If the interface address is not specified, the
-message is sent with a source address of the local interface the
-message is sent through.
-Note that on a multihomed host the
-interface used may vary from time to time with routing changes.
-.Pp
-The trap receiver will generally log event messages and other
-information from the server in a log file.
-While such monitor
-programs may also request their own trap dynamically, configuring a
-trap receiver will ensure that no messages are lost when the server
-is started.
-.It Cm hop Ar ...
-This command specifies a list of TTL values in increasing order, up to 8
-values can be specified.
-In manycast mode these values are used in turn in
-an expanding-ring search.
-The default is eight multiples of 32 starting at
-31.
-.El
.Sh FILES
-.Bl -tag -width /etc/ntp.drift -compact
-.It Pa /etc/ntp.conf
-the default name of the configuration file
-.It Pa ntp.keys
-private MD5 keys
-.It Pa ntpkey
-RSA private key
-.It Pa ntpkey_ Ns Ar host
-RSA public key
-.It Pa ntp_dh
-Diffie-Hellman agreement parameters
-.El
.Sh "SEE ALSO"
-.Sh SEE ALSO
-.Xr ntpd 1ntpdmdoc ,
-.Xr ntpdc 1ntpdcmdoc ,
-.Xr ntpq 1ntpqmdoc
-.Pp
-In addition to the manual pages provided,
-comprehensive documentation is available on the world wide web
-at
-.Li http://www.ntp.org/ .
-A snapshot of this documentation is available in HTML format in
-.Pa /usr/share/doc/ntp .
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 4)
-.%O RFC5905
-.Re
.Sh "AUTHORS"
The University of Delaware
.Sh "COPYRIGHT"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.Sh BUGS
-The syntax checking is not picky; some combinations of
-ridiculous and even hilarious options and modes may not be
-detected.
-.Pp
-The
-.Pa ntpkey_ Ns Ar host
-files are really digital
-certificates.
-These should be obtained via secure directory
-services when they become universally available.Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
+Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.Sh NOTES
-This document is derived from FreeBSD.
.Pp
This manual page was \fIAutoGen\fP-erated from the \fBntp.conf\fP
option definitions.
<p>This document describes the configuration file for the NTP Project's
<code>ntpd</code> program.
- <p>This document applies to version 4.2.7p331 of <code>ntp.conf</code>.
+ <p>This document applies to version 4.2.7p332 of <code>ntp.conf</code>.
<div class="shortcontents">
<h2>Short Contents</h2>
-.TH ntp.conf 5 "05 Dec 2012" "4.2.7p331" "File Formats"
+.TH ntp.conf 5 "06 Dec 2012" "4.2.7p332" "File Formats"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp.man)
.\"
-.\" It has been AutoGen-ed December 5, 2012 at 10:46:03 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:07 AM by AutoGen 5.16.2
.\" From the definitions ntp.conf.def
.\" and the template file agman-cmd.tpl
.\"
All arguments must be options.
.PP
.SH DESCRIPTION
-The
-.B
-configuration file is read at initial startup by the
-.Xr ntpd @NTPD_MS@
-daemon in order to specify the synchronization sources,
-modes and other related information.
-Usually, it is installed in the
-.Pa /etc
-directory,
-but could be installed elsewhere
-(see the daemon's
-c
-command line option).
-.PP
-The file format is similar to other
-.Ux
-configuration files.
-Comments begin with a
-.Ql #
-character and extend to the end of the line;
-blank lines are ignored.
-Configuration commands consist of an initial keyword
-followed by a list of arguments,
-some of which may be optional, separated by whitespace.
-Commands may not be continued over multiple lines.
-Arguments may be host names,
-host addresses written in numeric, dotted-quad form,
-integers, floating point numbers (when specifying times in seconds)
-and text strings.
-.PP
-The rest of this page describes the configuration and control options.
-The
-.Qq Notes on Configuring NTP and Setting up a NTP Subnet
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-contains an extended discussion of these options.
-In addition to the discussion of general
-.Sx Configuration Options ,
-there are sections describing the following supported functionality
-and the options used to control it:
-.in +4
-.ti -4
-\fB*\fP
-
-.Sx Authentication Support
-.ti -4
-\fB*\fP
-
-.Sx Monitoring Support
-.ti -4
-\fB*\fP
-
-.Sx Access Control Support
-.ti -4
-\fB*\fP
-
-.Sx Automatic NTP Configuration Options
-.ti -4
-\fB*\fP
-
-.Sx Reference Clock Support
-.ti -4
-\fB*\fP
-
-.Sx Miscellaneous Options
-.in -4
-.PP
-Following these is a section describing
-.Sx Miscellaneous Options .
-While there is a rich set of options available,
-the only required option is one or more
-.Ic pool ,
-.Ic server ,
-.Ic peer ,
-.Ic broadcast
-or
-.Ic manycastclient
-commands.
-.SH Configuration Support
-Following is a description of the configuration commands in
-NTPv4.
-These commands have the same basic functions as in NTPv3 and
-in some cases new functions and new arguments.
-There are two
-classes of commands, configuration commands that configure a
-persistent association with a remote server or peer or reference
-clock, and auxiliary commands that specify environmental variables
-that control various related operations.
-.SS Configuration Commands
-The various modes are determined by the command keyword and the
-type of the required IP address.
-Addresses are classed by type as
-(s) a remote server or peer (IPv4 class A, B and C), (b) the
-broadcast address of a local interface, (m) a multicast address (IPv4
-class D), or (r) a reference clock address (127.127.x.x).
-Note that
-only those options applicable to each command are listed below.
-Use
-of options not listed may not be caught as an error, but may result
-in some weird and even destructive behavior.
-.PP
-If the Basic Socket Interface Extensions for IPv6 (RFC-2553)
-is detected, support for the IPv6 address family is generated
-in addition to the default support of the IPv4 address family.
-In a few cases, including the reslist billboard generated
-by ntpdc, IPv6 addresses are automatically generated.
-IPv6 addresses can be identified by the presence of colons
-.Dq \&:
-in the address field.
-IPv6 addresses can be used almost everywhere where
-IPv4 addresses can be used,
-with the exception of reference clock addresses,
-which are always IPv4.
-.PP
-Note that in contexts where a host name is expected, a
-4
-qualifier preceding
-the host name forces DNS resolution to the IPv4 namespace,
-while a
-6
-qualifier forces DNS resolution to the IPv6 namespace.
-See IPv6 references for the
-equivalent classes for that address family.
-.TP
-.BR Xo Ic pool Ar address
-[ "\fIburst\fR" ]
-[ "\fIiburst\fR" ]
-[ "\fIversion\fR" "\fIversion\fR" ]
-[ "\fIprefer\fR" ]
-[ "\fIminpoll\fR" "\fIminpoll\fR" ]
-[ "\fImaxpoll\fR" "\fImaxpoll\fR" ]
-.Xc
-.TP
-.BR Xo Ic server Ar address
-[ "\fIkey\fR" "\fIkey\fR" \&| "\fIautokey\fR" ]
-[ "\fIburst\fR" ]
-[ "\fIiburst\fR" ]
-[ "\fIversion\fR" "\fIversion\fR" ]
-[ "\fIprefer\fR" ]
-[ "\fIminpoll\fR" "\fIminpoll\fR" ]
-[ "\fImaxpoll\fR" "\fImaxpoll\fR" ]
-.Xc
-.TP
-.BR Xo Ic peer Ar address
-[ "\fIkey\fR" "\fIkey\fR" \&| "\fIautokey\fR" ]
-[ "\fIversion\fR" "\fIversion\fR" ]
-[ "\fIprefer\fR" ]
-[ "\fIminpoll\fR" "\fIminpoll\fR" ]
-[ "\fImaxpoll\fR" "\fImaxpoll\fR" ]
-.Xc
-.TP
-.BR Xo Ic broadcast Ar address
-[ "\fIkey\fR" "\fIkey\fR" \&| "\fIautokey\fR" ]
-[ "\fIversion\fR" "\fIversion\fR" ]
-[ "\fIprefer\fR" ]
-[ "\fIminpoll\fR" "\fIminpoll\fR" ]
-[ "\fIttl\fR" "\fIttl\fR" ]
-.Xc
-.TP
-.BR Xo Ic manycastclient Ar address
-[ "\fIkey\fR" "\fIkey\fR" \&| "\fIautokey\fR" ]
-[ "\fIversion\fR" "\fIversion\fR" ]
-[ "\fIprefer\fR" ]
-[ "\fIminpoll\fR" "\fIminpoll\fR" ]
-[ "\fImaxpoll\fR" "\fImaxpoll\fR" ]
-[ "\fIttl\fR" "\fIttl\fR" ]
-.Xc
-.PP
-These five commands specify the time server name or address to
-be used and the mode in which to operate.
-The
-\fIaddress\fR
-can be
-either a DNS name or an IP address in dotted-quad notation.
-Additional information on association behavior can be found in the
-.Qq Association Management
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.TP
-.BR Ic pool
-For type s addresses, this command mobilizes a persistent
-client mode association with a number of remote servers.
-In this mode the local clock can synchronized to the
-remote server, but the remote server can never be synchronized to
-the local clock.
-.TP
-.BR Ic server
-For type s and r addresses, this command mobilizes a persistent
-client mode association with the specified remote server or local
-radio clock.
-In this mode the local clock can synchronized to the
-remote server, but the remote server can never be synchronized to
-the local clock.
-This command should
-.I not
-be used for type
-b or m addresses.
-.TP
-.BR Ic peer
-For type s addresses (only), this command mobilizes a
-persistent symmetric-active mode association with the specified
-remote peer.
-In this mode the local clock can be synchronized to
-the remote peer or the remote peer can be synchronized to the local
-clock.
-This is useful in a network of servers where, depending on
-various failure scenarios, either the local or remote peer may be
-the better source of time.
-This command should NOT be used for type
-b, m or r addresses.
-.TP
-.BR Ic broadcast
-For type b and m addresses (only), this
-command mobilizes a persistent broadcast mode association.
-Multiple
-commands can be used to specify multiple local broadcast interfaces
-(subnets) and/or multiple multicast groups.
-Note that local
-broadcast messages go only to the interface associated with the
-subnet specified, but multicast messages go to all interfaces.
-In broadcast mode the local server sends periodic broadcast
-messages to a client population at the
-\fIaddress\fR
-specified, which is usually the broadcast address on (one of) the
-local network(s) or a multicast address assigned to NTP.
-The IANA
-has assigned the multicast group address IPv4 224.0.1.1 and
-IPv6 ff05::101 (site local) exclusively to
-NTP, but other nonconflicting addresses can be used to contain the
-messages within administrative boundaries.
-Ordinarily, this
-specification applies only to the local server operating as a
-sender; for operation as a broadcast client, see the
-.Ic broadcastclient
-or
-.Ic multicastclient
-commands
-below.
-.TP
-.BR Ic manycastclient
-For type m addresses (only), this command mobilizes a
-manycast client mode association for the multicast address
-specified.
-In this case a specific address must be supplied which
-matches the address used on the
-.Ic manycastserver
-command for
-the designated manycast servers.
-The NTP multicast address
-224.0.1.1 assigned by the IANA should NOT be used, unless specific
-means are taken to avoid spraying large areas of the Internet with
-these messages and causing a possibly massive implosion of replies
-at the sender.
-The
-.Ic manycastserver
-command specifies that the local server
-is to operate in client mode with the remote servers that are
-discovered as the result of broadcast/multicast messages.
-The
-client broadcasts a request message to the group address associated
-with the specified
-\fIaddress\fR
-and specifically enabled
-servers respond to these messages.
-The client selects the servers
-providing the best time and continues as with the
-.Ic server
-command.
-The remaining servers are discarded as if never
-heard.
-.PP
-Options:
-.TP
-.BR Cm autokey
-All packets sent to and received from the server or peer are to
-include authentication fields encrypted using the autokey scheme
-described in
-.Sx Authentication Options .
-.TP
-.BR Cm burst
-when the server is reachable, send a burst of eight packets
-instead of the usual one.
-The packet spacing is normally 2 s;
-however, the spacing between the first and second packets
-can be changed with the calldelay command to allow
-additional time for a modem or ISDN call to complete.
-This is designed to improve timekeeping quality
-with the
-.Ic server
-command and s addresses.
-.TP
-.BR Cm iburst
-When the server is unreachable, send a burst of eight packets
-instead of the usual one.
-The packet spacing is normally 2 s;
-however, the spacing between the first two packets can be
-changed with the calldelay command to allow
-additional time for a modem or ISDN call to complete.
-This is designed to speed the initial synchronization
-acquisition with the
-.Ic server
-command and s addresses and when
-.Xr ntpd @NTPD_MS@
-is started with the
-q
-option.
-.TP
-.BR Cm key Ar key
-All packets sent to and received from the server or peer are to
-include authentication fields encrypted using the specified
-\fIkey\fR
-identifier with values from 1 to 65534, inclusive.
-The
-default is to include no encryption field.
-.TP
-.BR Cm minpoll Ar minpoll
-.TP
-.BR Cm maxpoll Ar maxpoll
-These options specify the minimum and maximum poll intervals
-for NTP messages, as a power of 2 in seconds
-The maximum poll
-interval defaults to 10 (1,024 s), but can be increased by the
-.Cm maxpoll
-option to an upper limit of 17 (36.4 h).
-The
-minimum poll interval defaults to 6 (64 s), but can be decreased by
-the
-.Cm minpoll
-option to a lower limit of 4 (16 s).
-.TP
-.BR Cm noselect
-Marks the server as unused, except for display purposes.
-The server is discarded by the selection algroithm.
-.TP
-.BR Cm prefer
-Marks the server as preferred.
-All other things being equal,
-this host will be chosen for synchronization among a set of
-correctly operating hosts.
-See the
-.Qq Mitigation Rules and the prefer Keyword
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-for further information.
-.TP
-.BR Cm ttl Ar ttl
-This option is used only with broadcast server and manycast
-client modes.
-It specifies the time-to-live
-\fIttl\fR
-to
-use on broadcast server and multicast server and the maximum
-\fIttl\fR
-for the expanding ring search with manycast
-client packets.
-Selection of the proper value, which defaults to
-127, is something of a black art and should be coordinated with the
-network administrator.
-.TP
-.BR Cm version Ar version
-Specifies the version number to be used for outgoing NTP
-packets.
-Versions 1-4 are the choices, with version 4 the
-default.
-.SS Auxiliary Commands
-.TP
-.BR Ic broadcastclient
-This command enables reception of broadcast server messages to
-any local interface (type b) address.
-Upon receiving a message for
-the first time, the broadcast client measures the nominal server
-propagation delay using a brief client/server exchange with the
-server, then enters the broadcast client mode, in which it
-synchronizes to succeeding broadcast messages.
-Note that, in order
-to avoid accidental or malicious disruption in this mode, both the
-server and client should operate using symmetric-key or public-key
-authentication as described in
-.Sx Authentication Options .
-.TP
-.BR Ic manycastserver Ar address ...
-This command enables reception of manycast client messages to
-the multicast group address(es) (type m) specified.
-At least one
-address is required, but the NTP multicast address 224.0.1.1
-assigned by the IANA should NOT be used, unless specific means are
-taken to limit the span of the reply and avoid a possibly massive
-implosion at the original sender.
-Note that, in order to avoid
-accidental or malicious disruption in this mode, both the server
-and client should operate using symmetric-key or public-key
-authentication as described in
-.Sx Authentication Options .
-.TP
-.BR Ic multicastclient Ar address ...
-This command enables reception of multicast server messages to
-the multicast group address(es) (type m) specified.
-Upon receiving
-a message for the first time, the multicast client measures the
-nominal server propagation delay using a brief client/server
-exchange with the server, then enters the broadcast client mode, in
-which it synchronizes to succeeding multicast messages.
-Note that,
-in order to avoid accidental or malicious disruption in this mode,
-both the server and client should operate using symmetric-key or
-public-key authentication as described in
-.Sx Authentication Options .
-.SH Authentication Support
-Authentication support allows the NTP client to verify that the
-server is in fact known and trusted and not an intruder intending
-accidentally or on purpose to masquerade as that server.
-The NTPv3
-specification RFC-1305 defines a scheme which provides
-cryptographic authentication of received NTP packets.
-Originally,
-this was done using the Data Encryption Standard (DES) algorithm
-operating in Cipher Block Chaining (CBC) mode, commonly called
-DES-CBC.
-Subsequently, this was replaced by the RSA Message Digest
-5 (MD5) algorithm using a private key, commonly called keyed-MD5.
-Either algorithm computes a message digest, or one-way hash, which
-can be used to verify the server has the correct private key and
-key identifier.
-.PP
-NTPv4 retains the NTPv3 scheme, properly described as symmetric key
-cryptography and, in addition, provides a new Autokey scheme
-based on public key cryptography.
-Public key cryptography is generally considered more secure
-than symmetric key cryptography, since the security is based
-on a private value which is generated by each server and
-never revealed.
-With Autokey all key distribution and
-management functions involve only public values, which
-considerably simplifies key distribution and storage.
-Public key management is based on X.509 certificates,
-which can be provided by commercial services or
-produced by utility programs in the OpenSSL software library
-or the NTPv4 distribution.
-.PP
-While the algorithms for symmetric key cryptography are
-included in the NTPv4 distribution, public key cryptography
-requires the OpenSSL software library to be installed
-before building the NTP distribution.
-Directions for doing that
-are on the Building and Installing the Distribution page.
-.PP
-Authentication is configured separately for each association
-using the
-.Cm key
-or
-.Cm autokey
-subcommand on the
-.Ic peer ,
-.Ic server ,
-.Ic broadcast
-and
-.Ic manycastclient
-configuration commands as described in
-.Sx Configuration Options
-page.
-The authentication
-options described below specify the locations of the key files,
-if other than default, which symmetric keys are trusted
-and the interval between various operations, if other than default.
-.PP
-Authentication is always enabled,
-although ineffective if not configured as
-described below.
-If a NTP packet arrives
-including a message authentication
-code (MAC), it is accepted only if it
-passes all cryptographic checks.
-The
-checks require correct key ID, key value
-and message digest.
-If the packet has
-been modified in any way or replayed
-by an intruder, it will fail one or more
-of these checks and be discarded.
-Furthermore, the Autokey scheme requires a
-preliminary protocol exchange to obtain
-the server certificate, verify its
-credentials and initialize the protocol
-.PP
-The
-.Cm auth
-flag controls whether new associations or
-remote configuration commands require cryptographic authentication.
-This flag can be set or reset by the
-.Ic enable
-and
-.Ic disable
-commands and also by remote
-configuration commands sent by a
-.Xr ntpdc @NTPDC_MS@
-program running in
-another machine.
-If this flag is enabled, which is the default
-case, new broadcast client and symmetric passive associations and
-remote configuration commands must be cryptographically
-authenticated using either symmetric key or public key cryptography.
-If this
-flag is disabled, these operations are effective
-even if not cryptographic
-authenticated.
-It should be understood
-that operating with the
-.Ic auth
-flag disabled invites a significant vulnerability
-where a rogue hacker can
-masquerade as a falseticker and seriously
-disrupt system timekeeping.
-It is
-important to note that this flag has no purpose
-other than to allow or disallow
-a new association in response to new broadcast
-and symmetric active messages
-and remote configuration commands and, in particular,
-the flag has no effect on
-the authentication process itself.
-.PP
-An attractive alternative where multicast support is available
-is manycast mode, in which clients periodically troll
-for servers as described in the
-.Sx Automatic NTP Configuration Options
-page.
-Either symmetric key or public key
-cryptographic authentication can be used in this mode.
-The principle advantage
-of manycast mode is that potential servers need not be
-configured in advance,
-since the client finds them during regular operation,
-and the configuration
-files for all clients can be identical.
-.PP
-The security model and protocol schemes for
-both symmetric key and public key
-cryptography are summarized below;
-further details are in the briefings, papers
-and reports at the NTP project page linked from
-.Li http://www.ntp.org/ .
-.SS Symmetric-Key Cryptography
-The original RFC-1305 specification allows any one of possibly
-65,534 keys, each distinguished by a 32-bit key identifier, to
-authenticate an association.
-The servers and clients involved must
-agree on the key and key identifier to
-authenticate NTP packets.
-Keys and
-related information are specified in a key
-file, usually called
-.Pa ntp.keys ,
-which must be distributed and stored using
-secure means beyond the scope of the NTP protocol itself.
-Besides the keys used
-for ordinary NTP associations,
-additional keys can be used as passwords for the
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-utility programs.
-.PP
-When
-.Xr ntpd @NTPD_MS@
-is first started, it reads the key file specified in the
-.Ic keys
-configuration command and installs the keys
-in the key cache.
-However,
-individual keys must be activated with the
-.Ic trusted
-command before use.
-This
-allows, for instance, the installation of possibly
-several batches of keys and
-then activating or deactivating each batch
-remotely using
-.Xr ntpdc @NTPDC_MS@ .
-This also provides a revocation capability that can be used
-if a key becomes compromised.
-The
-.Ic requestkey
-command selects the key used as the password for the
-.Xr ntpdc @NTPDC_MS@
-utility, while the
-.Ic controlkey
-command selects the key used as the password for the
-.Xr ntpq @NTPQ_MS@
-utility.
-.SS Public Key Cryptography
-NTPv4 supports the original NTPv3 symmetric key scheme
-described in RFC-1305 and in addition the Autokey protocol,
-which is based on public key cryptography.
-The Autokey Version 2 protocol described on the Autokey Protocol
-page verifies packet integrity using MD5 message digests
-and verifies the source with digital signatures and any of several
-digest/signature schemes.
-Optional identity schemes described on the Identity Schemes
-page and based on cryptographic challenge/response algorithms
-are also available.
-Using all of these schemes provides strong security against
-replay with or without modification, spoofing, masquerade
-and most forms of clogging attacks.
-.\" .Pp
-.\" The cryptographic means necessary for all Autokey operations
-.\" is provided by the OpenSSL software library.
-.\" This library is available from http://www.openssl.org/
-.\" and can be installed using the procedures outlined
-.\" in the Building and Installing the Distribution page.
-.\" Once installed,
-.\" the configure and build
-.\" process automatically detects the library and links
-.\" the library routines required.
-.PP
-The Autokey protocol has several modes of operation
-corresponding to the various NTP modes supported.
-Most modes use a special cookie which can be
-computed independently by the client and server,
-but encrypted in transmission.
-All modes use in addition a variant of the S-KEY scheme,
-in which a pseudo-random key list is generated and used
-in reverse order.
-These schemes are described along with an executive summary,
-current status, briefing slides and reading list on the
-.Sx Autonomous Authentication
-page.
-.PP
-The specific cryptographic environment used by Autokey servers
-and clients is determined by a set of files
-and soft links generated by the
-.Xr ntp-keygen 1ntpkeygenmdoc
-program.
-This includes a required host key file,
-required certificate file and optional sign key file,
-leapsecond file and identity scheme files.
-The
-digest/signature scheme is specified in the X.509 certificate
-along with the matching sign key.
-There are several schemes
-available in the OpenSSL software library, each identified
-by a specific string such as
-.Cm md5WithRSAEncryption ,
-which stands for the MD5 message digest with RSA
-encryption scheme.
-The current NTP distribution supports
-all the schemes in the OpenSSL library, including
-those based on RSA and DSA digital signatures.
-.PP
-NTP secure groups can be used to define cryptographic compartments
-and security hierarchies.
-It is important that every host
-in the group be able to construct a certificate trail to one
-or more trusted hosts in the same group.
-Each group
-host runs the Autokey protocol to obtain the certificates
-for all hosts along the trail to one or more trusted hosts.
-This requires the configuration file in all hosts to be
-engineered so that, even under anticipated failure conditions,
-the NTP subnet will form such that every group host can find
-a trail to at least one trusted host.
-.SS Naming and Addressing
-It is important to note that Autokey does not use DNS to
-resolve addresses, since DNS can't be completely trusted
-until the name servers have synchronized clocks.
-The cryptographic name used by Autokey to bind the host identity
-credentials and cryptographic values must be independent
-of interface, network and any other naming convention.
-The name appears in the host certificate in either or both
-the subject and issuer fields, so protection against
-DNS compromise is essential.
-.PP
-By convention, the name of an Autokey host is the name returned
-by the Unix
-.Xr gethostname 2
-system call or equivalent in other systems.
-By the system design
-model, there are no provisions to allow alternate names or aliases.
-However, this is not to say that DNS aliases, different names
-for each interface, etc., are constrained in any way.
-.PP
-It is also important to note that Autokey verifies authenticity
-using the host name, network address and public keys,
-all of which are bound together by the protocol specifically
-to deflect masquerade attacks.
-For this reason Autokey
-includes the source and destinatino IP addresses in message digest
-computations and so the same addresses must be available
-at both the server and client.
-For this reason operation
-with network address translation schemes is not possible.
-This reflects the intended robust security model where government
-and corporate NTP servers are operated outside firewall perimeters.
-.SS Operation
-A specific combination of authentication scheme (none,
-symmetric key, public key) and identity scheme is called
-a cryptotype, although not all combinations are compatible.
-There may be management configurations where the clients,
-servers and peers may not all support the same cryptotypes.
-A secure NTPv4 subnet can be configured in many ways while
-keeping in mind the principles explained above and
-in this section.
-Note however that some cryptotype
-combinations may successfully interoperate with each other,
-but may not represent good security practice.
-.PP
-The cryptotype of an association is determined at the time
-of mobilization, either at configuration time or some time
-later when a message of appropriate cryptotype arrives.
-When mobilized by a
-.Ic server
-or
-.Ic peer
-configuration command and no
-.Ic key
-or
-.Ic autokey
-subcommands are present, the association is not
-authenticated; if the
-.Ic key
-subcommand is present, the association is authenticated
-using the symmetric key ID specified; if the
-.Ic autokey
-subcommand is present, the association is authenticated
-using Autokey.
-.PP
-When multiple identity schemes are supported in the Autokey
-protocol, the first message exchange determines which one is used.
-The client request message contains bits corresponding
-to which schemes it has available.
-The server response message
-contains bits corresponding to which schemes it has available.
-Both server and client match the received bits with their own
-and select a common scheme.
-.PP
-Following the principle that time is a public value,
-a server responds to any client packet that matches
-its cryptotype capabilities.
-Thus, a server receiving
-an unauthenticated packet will respond with an unauthenticated
-packet, while the same server receiving a packet of a cryptotype
-it supports will respond with packets of that cryptotype.
-However, unconfigured broadcast or manycast client
-associations or symmetric passive associations will not be
-mobilized unless the server supports a cryptotype compatible
-with the first packet received.
-By default, unauthenticated associations will not be mobilized
-unless overridden in a decidedly dangerous way.
-.PP
-Some examples may help to reduce confusion.
-Client Alice has no specific cryptotype selected.
-Server Bob has both a symmetric key file and minimal Autokey files.
-Alice's unauthenticated messages arrive at Bob, who replies with
-unauthenticated messages.
-Cathy has a copy of Bob's symmetric
-key file and has selected key ID 4 in messages to Bob.
-Bob verifies the message with his key ID 4.
-If it's the
-same key and the message is verified, Bob sends Cathy a reply
-authenticated with that key.
-If verification fails,
-Bob sends Cathy a thing called a crypto-NAK, which tells her
-something broke.
-She can see the evidence using the ntpq program.
-.PP
-Denise has rolled her own host key and certificate.
-She also uses one of the identity schemes as Bob.
-She sends the first Autokey message to Bob and they
-both dance the protocol authentication and identity steps.
-If all comes out okay, Denise and Bob continue as described above.
-.PP
-It should be clear from the above that Bob can support
-all the girls at the same time, as long as he has compatible
-authentication and identity credentials.
-Now, Bob can act just like the girls in his own choice of servers;
-he can run multiple configured associations with multiple different
-servers (or the same server, although that might not be useful).
-But, wise security policy might preclude some cryptotype
-combinations; for instance, running an identity scheme
-with one server and no authentication with another might not be wise.
-.SS Key Management
-The cryptographic values used by the Autokey protocol are
-incorporated as a set of files generated by the
-.Xr ntp-keygen 1ntpkeygenmdoc
-utility program, including symmetric key, host key and
-public certificate files, as well as sign key, identity parameters
-and leapseconds files.
-Alternatively, host and sign keys and
-certificate files can be generated by the OpenSSL utilities
-and certificates can be imported from public certificate
-authorities.
-Note that symmetric keys are necessary for the
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-utility programs.
-The remaining files are necessary only for the
-Autokey protocol.
-.PP
-Certificates imported from OpenSSL or public certificate
-authorities have certian limitations.
-The certificate should be in ASN.1 syntax, X.509 Version 3
-format and encoded in PEM, which is the same format
-used by OpenSSL.
-The overall length of the certificate encoded
-in ASN.1 must not exceed 1024 bytes.
-The subject distinguished
-name field (CN) is the fully qualified name of the host
-on which it is used; the remaining subject fields are ignored.
-The certificate extension fields must not contain either
-a subject key identifier or a issuer key identifier field;
-however, an extended key usage field for a trusted host must
-contain the value
-.Cm trustRoot ; .
-Other extension fields are ignored.
-.SS Authentication Commands
-.TP
-.BR Ic autokey Op Ar logsec
-Specifies the interval between regenerations of the session key
-list used with the Autokey protocol.
-Note that the size of the key
-list for each association depends on this interval and the current
-poll interval.
-The default value is 12 (4096 s or about 1.1 hours).
-For poll intervals above the specified interval, a session key list
-with a single entry will be regenerated for every message
-sent.
-.TP
-.BR Ic controlkey Ar key
-Specifies the key identifier to use with the
-.Xr ntpq @NTPQ_MS@
-utility, which uses the standard
-protocol defined in RFC-1305.
-The
-\fIkey\fR
-argument is
-the key identifier for a trusted key, where the value can be in the
-range 1 to 65,534, inclusive.
-.TP
-.BR Xo Ic crypto
-[ "\fIcert\fR" "\fIfile\fR" ]
-[ "\fIleap\fR" "\fIfile\fR" ]
-[ "\fIrandfile\fR" "\fIfile\fR" ]
-[ "\fIhost\fR" "\fIfile\fR" ]
-[ "\fIsign\fR" "\fIfile\fR" ]
-[ "\fIgq\fR" "\fIfile\fR" ]
-[ "\fIgqpar\fR" "\fIfile\fR" ]
-[ "\fIiffpar\fR" "\fIfile\fR" ]
-[ "\fImvpar\fR" "\fIfile\fR" ]
-[ "\fIpw\fR" "\fIpassword\fR" ]
-.Xc
-This command requires the OpenSSL library.
-It activates public key
-cryptography, selects the message digest and signature
-encryption scheme and loads the required private and public
-values described above.
-If one or more files are left unspecified,
-the default names are used as described above.
-Unless the complete path and name of the file are specified, the
-location of a file is relative to the keys directory specified
-in the
-.Ic keysdir
-command or default
-.Pa /usr/local/etc .
-Following are the subcommands:
-.in +4
-.ti -4
-.IR Cm cert Ar file
-Specifies the location of the required host public certificate file.
-This overrides the link
-.Pa ntpkey_cert_ Ns Ar hostname
-in the keys directory.
-.ti -4
-.IR Cm gqpar Ar file
-Specifies the location of the optional GQ parameters file.
-This
-overrides the link
-.Pa ntpkey_gq_ Ns Ar hostname
-in the keys directory.
-.ti -4
-.IR Cm host Ar file
-Specifies the location of the required host key file.
-This overrides
-the link
-.Pa ntpkey_key_ Ns Ar hostname
-in the keys directory.
-.ti -4
-.IR Cm iffpar Ar file
-Specifies the location of the optional IFF parameters file.This
-overrides the link
-.Pa ntpkey_iff_ Ns Ar hostname
-in the keys directory.
-.ti -4
-.IR Cm leap Ar file
-Specifies the location of the optional leapsecond file.
-This overrides the link
-.Pa ntpkey_leap
-in the keys directory.
-.ti -4
-.IR Cm mvpar Ar file
-Specifies the location of the optional MV parameters file.
-This
-overrides the link
-.Pa ntpkey_mv_ Ns Ar hostname
-in the keys directory.
-.ti -4
-.IR Cm pw Ar password
-Specifies the password to decrypt files containing private keys and
-identity parameters.
-This is required only if these files have been
-encrypted.
-.ti -4
-.IR Cm randfile Ar file
-Specifies the location of the random seed file used by the OpenSSL
-library.
-The defaults are described in the main text above.
-.ti -4
-.IR Cm sign Ar file
-Specifies the location of the optional sign key file.
-This overrides
-the link
-.Pa ntpkey_sign_ Ns Ar hostname
-in the keys directory.
-If this file is
-not found, the host key is also the sign key.
-.in -4
-.TP
-.BR Ic keys Ar keyfile
-Specifies the complete path and location of the MD5 key file
-containing the keys and key identifiers used by
-.Xr ntpd @NTPD_MS@ ,
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-when operating with symmetric key cryptography.
-This is the same operation as the
-k
-command line option.
-.TP
-.BR Ic keysdir Ar path
-This command specifies the default directory path for
-cryptographic keys, parameters and certificates.
-The default is
-.Pa /usr/local/etc/ .
-.TP
-.BR Ic requestkey Ar key
-Specifies the key identifier to use with the
-.Xr ntpdc @NTPDC_MS@
-utility program, which uses a
-proprietary protocol specific to this implementation of
-.Xr ntpd @NTPD_MS@ .
-The
-\fIkey\fR
-argument is a key identifier
-for the trusted key, where the value can be in the range 1 to
-65,534, inclusive.
-.TP
-.BR Ic revoke Ar logsec
-Specifies the interval between re-randomization of certain
-cryptographic values used by the Autokey scheme, as a power of 2 in
-seconds.
-These values need to be updated frequently in order to
-deflect brute-force attacks on the algorithms of the scheme;
-however, updating some values is a relatively expensive operation.
-The default interval is 16 (65,536 s or about 18 hours).
-For poll
-intervals above the specified interval, the values will be updated
-for every message sent.
-.TP
-.BR Ic trustedkey Ar key ...
-Specifies the key identifiers which are trusted for the
-purposes of authenticating peers with symmetric key cryptography,
-as well as keys used by the
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-programs.
-The authentication procedures require that both the local
-and remote servers share the same key and key identifier for this
-purpose, although different keys can be used with different
-servers.
-The
-\fIkey\fR
-arguments are 32-bit unsigned
-integers with values from 1 to 65,534.
-.SS Error Codes
-The following error codes are reported via the NTP control
-and monitoring protocol trap mechanism.
-.TP
-.BR 101
-.Pq bad field format or length
-The packet has invalid version, length or format.
-.TP
-.BR 102
-.Pq bad timestamp
-The packet timestamp is the same or older than the most recent received.
-This could be due to a replay or a server clock time step.
-.TP
-.BR 103
-.Pq bad filestamp
-The packet filestamp is the same or older than the most recent received.
-This could be due to a replay or a key file generation error.
-.TP
-.BR 104
-.Pq bad or missing public key
-The public key is missing, has incorrect format or is an unsupported type.
-.TP
-.BR 105
-.Pq unsupported digest type
-The server requires an unsupported digest/signature scheme.
-.TP
-.BR 106
-.Pq mismatched digest types
-Not used.
-.TP
-.BR 107
-.Pq bad signature length
-The signature length does not match the current public key.
-.TP
-.BR 108
-.Pq signature not verified
-The message fails the signature check.
-It could be bogus or signed by a
-different private key.
-.TP
-.BR 109
-.Pq certificate not verified
-The certificate is invalid or signed with the wrong key.
-.TP
-.BR 110
-.Pq certificate not verified
-The certificate is not yet valid or has expired or the signature could not
-be verified.
-.TP
-.BR 111
-.Pq bad or missing cookie
-The cookie is missing, corrupted or bogus.
-.TP
-.BR 112
-.Pq bad or missing leapseconds table
-The leapseconds table is missing, corrupted or bogus.
-.TP
-.BR 113
-.Pq bad or missing certificate
-The certificate is missing, corrupted or bogus.
-.TP
-.BR 114
-.Pq bad or missing identity
-The identity key is missing, corrupt or bogus.
-.SH Monitoring Support
-.Xr ntpd @NTPD_MS@
-includes a comprehensive monitoring facility suitable
-for continuous, long term recording of server and client
-timekeeping performance.
-See the
-.Ic statistics
-command below
-for a listing and example of each type of statistics currently
-supported.
-Statistic files are managed using file generation sets
-and scripts in the
-.Pa ./scripts
-directory of this distribution.
-Using
-these facilities and
-.Ux
-.Xr cron 8
-jobs, the data can be
-automatically summarized and archived for retrospective analysis.
-.SS Monitoring Commands
-.TP
-.BR Ic statistics Ar name ...
-Enables writing of statistics records.
-Currently, four kinds of
-\fIname\fR
-statistics are supported.
-.in +4
-.ti -4
-.IR Cm clockstats
-Enables recording of clock driver statistics information.
-Each update
-received from a clock driver appends a line of the following form to
-the file generation set named
-.Cm clockstats :
-.br
-.in +4
-.nf
-49213 525.624 127.127.4.1 93 226 00:08:29.606 D
-.in -4
-.fi
-.PP
-The first two fields show the date (Modified Julian Day) and time
-(seconds and fraction past UTC midnight).
-The next field shows the
-clock address in dotted-quad notation.
-The final field shows the last
-timecode received from the clock in decoded ASCII format, where
-meaningful.
-In some clock drivers a good deal of additional information
-can be gathered and displayed as well.
-See information specific to each
-clock for further details.
-.ti -4
-.IR Cm cryptostats
-This option requires the OpenSSL cryptographic software library.
-It
-enables recording of cryptographic public key protocol information.
-Each message received by the protocol module appends a line of the
-following form to the file generation set named
-.Cm cryptostats :
-.br
-.in +4
-.nf
-49213 525.624 127.127.4.1 message
-.in -4
-.fi
-.PP
-The first two fields show the date (Modified Julian Day) and time
-(seconds and fraction past UTC midnight).
-The next field shows the peer
-address in dotted-quad notation, The final message field includes the
-message type and certain ancillary information.
-See the
-.Sx Authentication Options
-section for further information.
-.ti -4
-.IR Cm loopstats
-Enables recording of loop filter statistics information.
-Each
-update of the local clock outputs a line of the following form to
-the file generation set named
-.Cm loopstats :
-.br
-.in +4
-.nf
-50935 75440.031 0.000006019 13.778190 0.000351733 0.0133806
-.in -4
-.fi
-.PP
-The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight).
-The next five fields
-show time offset (seconds), frequency offset (parts per million -
-PPM), RMS jitter (seconds), Allan deviation (PPM) and clock
-discipline time constant.
-.ti -4
-.IR Cm peerstats
-Enables recording of peer statistics information.
-This includes
-statistics records of all peers of a NTP server and of special
-signals, where present and configured.
-Each valid update appends a
-line of the following form to the current element of a file
-generation set named
-.Cm peerstats :
-.br
-.in +4
-.nf
-48773 10847.650 127.127.4.1 9714 -0.001605376 0.000000000 0.001424877 0.000958674
-.in -4
-.fi
-.PP
-The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight).
-The next two fields
-show the peer address in dotted-quad notation and status,
-respectively.
-The status field is encoded in hex in the format
-described in Appendix A of the NTP specification RFC 1305.
-The final four fields show the offset,
-delay, dispersion and RMS jitter, all in seconds.
-.ti -4
-.IR Cm rawstats
-Enables recording of raw-timestamp statistics information.
-This
-includes statistics records of all peers of a NTP server and of
-special signals, where present and configured.
-Each NTP message
-received from a peer or clock driver appends a line of the
-following form to the file generation set named
-.Cm rawstats :
-.br
-.in +4
-.nf
-50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 3102453281.58622800031 02453332.540806000 3102453332.541458000
-.in -4
-.fi
-.PP
-The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight).
-The next two fields
-show the remote peer or clock address followed by the local address
-in dotted-quad notation.
-The final four fields show the originate,
-receive, transmit and final NTP timestamps in order.
-The timestamp
-values are as received and before processing by the various data
-smoothing and mitigation algorithms.
-.ti -4
-.IR Cm sysstats
-Enables recording of ntpd statistics counters on a periodic basis.
-Each
-hour a line of the following form is appended to the file generation
-set named
-.Cm sysstats :
-.br
-.in +4
-.nf
-50928 2132.543 36000 81965 0 9546 56 71793 512 540 10 147
-.in -4
-.fi
-.PP
-The first two fields show the date (Modified Julian Day) and time
-(seconds and fraction past UTC midnight).
-The remaining ten fields show
-the statistics counter values accumulated since the last generated
-line.
-.in +4
-.ti -4
-.IR Time since restart Cm 36000
-Time in hours since the system was last rebooted.
-.ti -4
-.IR Packets received Cm 81965
-Total number of packets received.
-.ti -4
-.IR Packets processed Cm 0
-Number of packets received in response to previous packets sent
-.ti -4
-.IR Current version Cm 9546
-Number of packets matching the current NTP version.
-.ti -4
-.IR Previous version Cm 56
-Number of packets matching the previous NTP version.
-.ti -4
-.IR Bad version Cm 71793
-Number of packets matching neither NTP version.
-.ti -4
-.IR Access denied Cm 512
-Number of packets denied access for any reason.
-.ti -4
-.IR Bad length or format Cm 540
-Number of packets with invalid length, format or port number.
-.ti -4
-.IR Bad authentication Cm 10
-Number of packets not verified as authentic.
-.ti -4
-.IR Rate exceeded Cm 147
-Number of packets discarded due to rate limitation.
-.in -4
-.ti -4
-.IR Cm statsdir Ar directory_path
-Indicates the full path of a directory where statistics files
-should be created (see below).
-This keyword allows
-the (otherwise constant)
-.Cm filegen
-filename prefix to be modified for file generation sets, which
-is useful for handling statistics logs.
-.ti -4
-.IR Cm filegen Ar name Xo
-[ "\fIfile\fR" "\fIfilename\fR" ]
-[ "\fItype\fR" "\fItypename\fR" ]
-[ "\fIlink\fR" | nolink ]
-[ "\fIenable\fR" | disable ]
-.Xc
-Configures setting of generation file set name.
-Generation
-file sets provide a means for handling files that are
-continuously growing during the lifetime of a server.
-Server statistics are a typical example for such files.
-Generation file sets provide access to a set of files used
-to store the actual data.
-At any time at most one element
-of the set is being written to.
-The type given specifies
-when and how data will be directed to a new element of the set.
-This way, information stored in elements of a file set
-that are currently unused are available for administrational
-operations without the risk of disturbing the operation of ntpd.
-(Most important: they can be removed to free space for new data
-produced.)
-.PP
-Note that this command can be sent from the
-.Xr ntpdc @NTPDC_MS@
-program running at a remote location.
-.in +4
-.ti -4
-.IR Cm name
-This is the type of the statistics records, as shown in the
-.Cm statistics
-command.
-.ti -4
-.IR Cm file Ar filename
-This is the file name for the statistics records.
-Filenames of set
-members are built from three concatenated elements
-\fICm prefix ,\fR
-\fICm filename\fR
-and
-\fICm suffix :\fR
-.in +4
-.ti -4
-.IR Cm prefix
-This is a constant filename path.
-It is not subject to
-modifications via the
-\fIfilegen\fR
-option.
-It is defined by the
-server, usually specified as a compile-time constant.
-It may,
-however, be configurable for individual file generation sets
-via other commands.
-For example, the prefix used with
-\fIloopstats\fR
-and
-\fIpeerstats\fR
-generation can be configured using the
-\fIstatsdir\fR
-option explained above.
-.ti -4
-.IR Cm filename
-This string is directly concatenated to the prefix mentioned
-above (no intervening
-.Ql / ) .
-This can be modified using
-the file argument to the
-\fIfilegen\fR
-statement.
-No
-.Pa ..
-elements are
-allowed in this component to prevent filenames referring to
-parts outside the filesystem hierarchy denoted by
-\fIprefix .\fR
-.ti -4
-.IR Cm suffix
-This part is reflects individual elements of a file set.
-It is
-generated according to the type of a file set.
-.in -4
-.ti -4
-.IR Cm type Ar typename
-A file generation set is characterized by its type.
-The following
-types are supported:
-.in +4
-.ti -4
-.IR Cm none
-The file set is actually a single plain file.
-.ti -4
-.IR Cm pid
-One element of file set is used per incarnation of a ntpd
-server.
-This type does not perform any changes to file set
-members during runtime, however it provides an easy way of
-separating files belonging to different
-.Xr ntpd @NTPD_MS@
-server incarnations.
-The set member filename is built by appending a
-.Ql \&.
-to concatenated
-\fIprefix\fR
-and
-\fIfilename\fR
-strings, and
-appending the decimal representation of the process ID of the
-.Xr ntpd @NTPD_MS@
-server process.
-.ti -4
-.IR Cm day
-One file generation set element is created per day.
-A day is
-defined as the period between 00:00 and 24:00 UTC.
-The file set
-member suffix consists of a
-.Ql \&.
-and a day specification in
-the form
-.Cm YYYYMMdd .
-.Cm YYYY
-is a 4-digit year number (e.g., 1992).
-.Cm MM
-is a two digit month number.
-.Cm dd
-is a two digit day number.
-Thus, all information written at 10 December 1992 would end up
-in a file named
-\fIprefix\fR
-\fIfilename Ns .19921210 .\fR
-.ti -4
-.IR Cm week
-Any file set member contains data related to a certain week of
-a year.
-The term week is defined by computing day-of-year
-modulo 7.
-Elements of such a file generation set are
-distinguished by appending the following suffix to the file set
-filename base: A dot, a 4-digit year number, the letter
-.Cm W ,
-and a 2-digit week number.
-For example, information from January,
-10th 1992 would end up in a file with suffix
-.No . Ns Ar 1992W1 .
-.ti -4
-.IR Cm month
-One generation file set element is generated per month.
-The
-file name suffix consists of a dot, a 4-digit year number, and
-a 2-digit month.
-.ti -4
-.IR Cm year
-One generation file element is generated per year.
-The filename
-suffix consists of a dot and a 4 digit year number.
-.ti -4
-.IR Cm age
-This type of file generation sets changes to a new element of
-the file set every 24 hours of server operation.
-The filename
-suffix consists of a dot, the letter
-.Cm a ,
-and an 8-digit number.
-This number is taken to be the number of seconds the server is
-running at the start of the corresponding 24-hour period.
-Information is only written to a file generation by specifying
-.Cm enable ;
-output is prevented by specifying
-.Cm disable .
-.in -4
-.ti -4
-.IR Cm link | nolink
-It is convenient to be able to access the current element of a file
-generation set by a fixed name.
-This feature is enabled by
-specifying
-.Cm link
-and disabled using
-.Cm nolink .
-If link is specified, a
-hard link from the current file set element to a file without
-suffix is created.
-When there is already a file with this name and
-the number of links of this file is one, it is renamed appending a
-dot, the letter
-.Cm C ,
-and the pid of the ntpd server process.
-When the
-number of links is greater than one, the file is unlinked.
-This
-allows the current file to be accessed by a constant name.
-.ti -4
-.IR Cm enable \&| Cm disable
-Enables or disables the recording function.
-.in -4
-.in -4
-.SH Access Control Support
-The
-.Xr ntpd @NTPD_MS@
-daemon implements a general purpose address/mask based restriction
-list.
-The list contains address/match entries sorted first
-by increasing address values and and then by increasing mask values.
-A match occurs when the bitwise AND of the mask and the packet
-source address is equal to the bitwise AND of the mask and
-address in the list.
-The list is searched in order with the
-last match found defining the restriction flags associated
-with the entry.
-Additional information and examples can be found in the
-.Qq Notes on Configuring NTP and Setting up a NTP Subnet
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.PP
-The restriction facility was implemented in conformance
-with the access policies for the original NSFnet backbone
-time servers.
-Later the facility was expanded to deflect
-cryptographic and clogging attacks.
-While this facility may
-be useful for keeping unwanted or broken or malicious clients
-from congesting innocent servers, it should not be considered
-an alternative to the NTP authentication facilities.
-Source address based restrictions are easily circumvented
-by a determined cracker.
-.PP
-Clients can be denied service because they are explicitly
-included in the restrict list created by the restrict command
-or implicitly as the result of cryptographic or rate limit
-violations.
-Cryptographic violations include certificate
-or identity verification failure; rate limit violations generally
-result from defective NTP implementations that send packets
-at abusive rates.
-Some violations cause denied service
-only for the offending packet, others cause denied service
-for a timed period and others cause the denied service for
-an indefinate period.
-When a client or network is denied access
-for an indefinate period, the only way at present to remove
-the restrictions is by restarting the server.
-.SS The Kiss-of-Death Packet
-Ordinarily, packets denied service are simply dropped with no
-further action except incrementing statistics counters.
-Sometimes a
-more proactive response is needed, such as a server message that
-explicitly requests the client to stop sending and leave a message
-for the system operator.
-A special packet format has been created
-for this purpose called the "kiss-of-death" (KoD) packet.
-KoD packets have the leap bits set unsynchronized and stratum set
-to zero and the reference identifier field set to a four-byte
-ASCII code.
-If the
-.Cm noserve
-or
-.Cm notrust
-flag of the matching restrict list entry is set,
-the code is "DENY"; if the
-.Cm limited
-flag is set and the rate limit
-is exceeded, the code is "RATE".
-Finally, if a cryptographic violation occurs, the code is "CRYP".
-.PP
-A client receiving a KoD performs a set of sanity checks to
-minimize security exposure, then updates the stratum and
-reference identifier peer variables, sets the access
-denied (TEST4) bit in the peer flash variable and sends
-a message to the log.
-As long as the TEST4 bit is set,
-the client will send no further packets to the server.
-The only way at present to recover from this condition is
-to restart the protocol at both the client and server.
-This
-happens automatically at the client when the association times out.
-It will happen at the server only if the server operator cooperates.
-.SS Access Control Commands
-.TP
-.BR Xo Ic discard
-[ "\fIaverage\fR" "\fIavg\fR" ]
-[ "\fIminimum\fR" "\fImin\fR" ]
-[ "\fImonitor\fR" "\fIprob\fR" ]
-.Xc
-Set the parameters of the
-.Cm limited
-facility which protects the server from
-client abuse.
-The
-.Cm average
-subcommand specifies the minimum average packet
-spacing, while the
-.Cm minimum
-subcommand specifies the minimum packet spacing.
-Packets that violate these minima are discarded
-and a kiss-o'-death packet returned if enabled.
-The default
-minimum average and minimum are 5 and 2, respectively.
-The monitor subcommand specifies the probability of discard
-for packets that overflow the rate-control window.
-.TP
-.BR Xo Ic restrict address
-[ "\fImask\fR" "\fImask\fR" ]
-[ "\fIflag\fR" ... ]
-.Xc
-The
-\fIaddress\fR
-argument expressed in
-dotted-quad form is the address of a host or network.
-Alternatively, the
-\fIaddress\fR
-argument can be a valid host DNS name.
-The
-\fImask\fR
-argument expressed in dotted-quad form defaults to
-.Cm 255.255.255.255 ,
-meaning that the
-\fIaddress\fR
-is treated as the address of an individual host.
-A default entry (address
-.Cm 0.0.0.0 ,
-mask
-.Cm 0.0.0.0 )
-is always included and is always the first entry in the list.
-Note that text string
-.Cm default ,
-with no mask option, may
-be used to indicate the default entry.
-In the current implementation,
-.Cm flag
-always
-restricts access, i.e., an entry with no flags indicates that free
-access to the server is to be given.
-The flags are not orthogonal,
-in that more restrictive flags will often make less restrictive
-ones redundant.
-The flags can generally be classed into two
-categories, those which restrict time service and those which
-restrict informational queries and attempts to do run-time
-reconfiguration of the server.
-One or more of the following flags
-may be specified:
-.in +4
-.ti -4
-.IR Cm ignore
-Deny packets of all kinds, including
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-queries.
-.ti -4
-.IR Cm kod
-If this flag is set when an access violation occurs, a kiss-o'-death
-(KoD) packet is sent.
-KoD packets are rate limited to no more than one
-per second.
-If another KoD packet occurs within one second after the
-last one, the packet is dropped.
-.ti -4
-.IR Cm limited
-Deny service if the packet spacing violates the lower limits specified
-in the discard command.
-A history of clients is kept using the
-monitoring capability of
-.Xr ntpd @NTPD_MS@ .
-Thus, monitoring is always active as
-long as there is a restriction entry with the
-.Cm limited
-flag.
-.ti -4
-.IR Cm lowpriotrap
-Declare traps set by matching hosts to be low priority.
-The
-number of traps a server can maintain is limited (the current limit
-is 3).
-Traps are usually assigned on a first come, first served
-basis, with later trap requestors being denied service.
-This flag
-modifies the assignment algorithm by allowing low priority traps to
-be overridden by later requests for normal priority traps.
-.ti -4
-.IR Cm nomodify
-Deny
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-queries which attempt to modify the state of the
-server (i.e., run time reconfiguration).
-Queries which return
-information are permitted.
-.ti -4
-.IR Cm noquery
-Deny
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-queries.
-Time service is not affected.
-.ti -4
-.IR Cm nopeer
-Deny packets which would result in mobilizing a new association.
-This
-includes broadcast and symmetric active packets when a configured
-association does not exist.
-.ti -4
-.IR Cm noserve
-Deny all packets except
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-queries.
-.ti -4
-.IR Cm notrap
-Decline to provide mode 6 control message trap service to matching
-hosts.
-The trap service is a subsystem of the ntpdq control message
-protocol which is intended for use by remote event logging programs.
-.ti -4
-.IR Cm notrust
-Deny service unless the packet is cryptographically authenticated.
-.ti -4
-.IR Cm ntpport
-This is actually a match algorithm modifier, rather than a
-restriction flag.
-Its presence causes the restriction entry to be
-matched only if the source port in the packet is the standard NTP
-UDP port (123).
-Both
-.Cm ntpport
-and
-.Cm non-ntpport
-may
-be specified.
-The
-.Cm ntpport
-is considered more specific and
-is sorted later in the list.
-.ti -4
-.IR Cm version
-Deny packets that do not match the current NTP version.
-.in -4
-.PP
-Default restriction list entries with the flags ignore, interface,
-ntpport, for each of the local host's interface addresses are
-inserted into the table at startup to prevent the server
-from attempting to synchronize to its own time.
-A default entry is also always present, though if it is
-otherwise unconfigured; no flags are associated
-with the default entry (i.e., everything besides your own
-NTP server is unrestricted).
-.SH Automatic NTP Configuration Options
-.SS Manycasting
-Manycasting is a automatic discovery and configuration paradigm
-new to NTPv4.
-It is intended as a means for a multicast client
-to troll the nearby network neighborhood to find cooperating
-manycast servers, validate them using cryptographic means
-and evaluate their time values with respect to other servers
-that might be lurking in the vicinity.
-The intended result is that each manycast client mobilizes
-client associations with some number of the "best"
-of the nearby manycast servers, yet automatically reconfigures
-to sustain this number of servers should one or another fail.
-.PP
-Note that the manycasting paradigm does not coincide
-with the anycast paradigm described in RFC-1546,
-which is designed to find a single server from a clique
-of servers providing the same service.
-The manycast paradigm is designed to find a plurality
-of redundant servers satisfying defined optimality criteria.
-.PP
-Manycasting can be used with either symmetric key
-or public key cryptography.
-The public key infrastructure (PKI)
-offers the best protection against compromised keys
-and is generally considered stronger, at least with relatively
-large key sizes.
-It is implemented using the Autokey protocol and
-the OpenSSL cryptographic library available from
-.Li http://www.openssl.org/ .
-The library can also be used with other NTPv4 modes
-as well and is highly recommended, especially for broadcast modes.
-.PP
-A persistent manycast client association is configured
-using the manycastclient command, which is similar to the
-server command but with a multicast (IPv4 class
-.Cm D
-or IPv6 prefix
-.Cm FF )
-group address.
-The IANA has designated IPv4 address 224.1.1.1
-and IPv6 address FF05::101 (site local) for NTP.
-When more servers are needed, it broadcasts manycast
-client messages to this address at the minimum feasible rate
-and minimum feasible time-to-live (TTL) hops, depending
-on how many servers have already been found.
-There can be as many manycast client associations
-as different group address, each one serving as a template
-for a future ephemeral unicast client/server association.
-.PP
-Manycast servers configured with the
-.Ic manycastserver
-command listen on the specified group address for manycast
-client messages.
-Note the distinction between manycast client,
-which actively broadcasts messages, and manycast server,
-which passively responds to them.
-If a manycast server is
-in scope of the current TTL and is itself synchronized
-to a valid source and operating at a stratum level equal
-to or lower than the manycast client, it replies to the
-manycast client message with an ordinary unicast server message.
-.PP
-The manycast client receiving this message mobilizes
-an ephemeral client/server association according to the
-matching manycast client template, but only if cryptographically
-authenticated and the server stratum is less than or equal
-to the client stratum.
-Authentication is explicitly required
-and either symmetric key or public key (Autokey) can be used.
-Then, the client polls the server at its unicast address
-in burst mode in order to reliably set the host clock
-and validate the source.
-This normally results
-in a volley of eight client/server at 2-s intervals
-during which both the synchronization and cryptographic
-protocols run concurrently.
-Following the volley,
-the client runs the NTP intersection and clustering
-algorithms, which act to discard all but the "best"
-associations according to stratum and synchronization
-distance.
-The surviving associations then continue
-in ordinary client/server mode.
-.PP
-The manycast client polling strategy is designed to reduce
-as much as possible the volume of manycast client messages
-and the effects of implosion due to near-simultaneous
-arrival of manycast server messages.
-The strategy is determined by the
-.Ic manycastclient ,
-.Ic tos
-and
-.Ic ttl
-configuration commands.
-The manycast poll interval is
-normally eight times the system poll interval,
-which starts out at the
-.Cm minpoll
-value specified in the
-.Ic manycastclient ,
-command and, under normal circumstances, increments to the
-.Cm maxpolll
-value specified in this command.
-Initially, the TTL is
-set at the minimum hops specified by the ttl command.
-At each retransmission the TTL is increased until reaching
-the maximum hops specified by this command or a sufficient
-number client associations have been found.
-Further retransmissions use the same TTL.
-.PP
-The quality and reliability of the suite of associations
-discovered by the manycast client is determined by the NTP
-mitigation algorithms and the
-.Cm minclock
-and
-.Cm minsane
-values specified in the
-.Ic tos
-configuration command.
-At least
-.Cm minsane
-candidate servers must be available and the mitigation
-algorithms produce at least
-.Cm minclock
-survivors in order to synchronize the clock.
-Byzantine agreement principles require at least four
-candidates in order to correctly discard a single falseticker.
-For legacy purposes,
-.Cm minsane
-defaults to 1 and
-.Cm minclock
-defaults to 3.
-For manycast service
-.Cm minsane
-should be explicitly set to 4, assuming at least that
-number of servers are available.
-.PP
-If at least
-.Cm minclock
-servers are found, the manycast poll interval is immediately
-set to eight times
-.Cm maxpoll .
-If less than
-.Cm minclock
-servers are found when the TTL has reached the maximum hops,
-the manycast poll interval is doubled.
-For each transmission
-after that, the poll interval is doubled again until
-reaching the maximum of eight times
-.Cm maxpoll .
-Further transmissions use the same poll interval and
-TTL values.
-Note that while all this is going on,
-each client/server association found is operating normally
-it the system poll interval.
-.PP
-Administratively scoped multicast boundaries are normally
-specified by the network router configuration and,
-in the case of IPv6, the link/site scope prefix.
-By default, the increment for TTL hops is 32 starting
-from 31; however, the
-.Ic ttl
-configuration command can be
-used to modify the values to match the scope rules.
-.PP
-It is often useful to narrow the range of acceptable
-servers which can be found by manycast client associations.
-Because manycast servers respond only when the client
-stratum is equal to or greater than the server stratum,
-primary (stratum 1) servers fill find only primary servers
-in TTL range, which is probably the most common objective.
-However, unless configured otherwise, all manycast clients
-in TTL range will eventually find all primary servers
-in TTL range, which is probably not the most common
-objective in large networks.
-The
-.Ic tos
-command can be used to modify this behavior.
-Servers with stratum below
-.Cm floor
-or above
-.Cm ceiling
-specified in the
-.Ic tos
-command are strongly discouraged during the selection
-process; however, these servers may be temporally
-accepted if the number of servers within TTL range is
-less than
-.Cm minclock .
-.PP
-The above actions occur for each manycast client message,
-which repeats at the designated poll interval.
-However, once the ephemeral client association is mobilized,
-subsequent manycast server replies are discarded,
-since that would result in a duplicate association.
-If during a poll interval the number of client associations
-falls below
-.Cm minclock ,
-all manycast client prototype associations are reset
-to the initial poll interval and TTL hops and operation
-resumes from the beginning.
-It is important to avoid
-frequent manycast client messages, since each one requires
-all manycast servers in TTL range to respond.
-The result could well be an implosion, either minor or major,
-depending on the number of servers in range.
-The recommended value for
-.Cm maxpoll
-is 12 (4,096 s).
-.PP
-It is possible and frequently useful to configure a host
-as both manycast client and manycast server.
-A number of hosts configured this way and sharing a common
-group address will automatically organize themselves
-in an optimum configuration based on stratum and
-synchronization distance.
-For example, consider an NTP
-subnet of two primary servers and a hundred or more
-dependent clients.
-With two exceptions, all servers
-and clients have identical configuration files including both
-.Ic multicastclient
-and
-.Ic multicastserver
-commands using, for instance, multicast group address
-239.1.1.1.
-The only exception is that each primary server
-configuration file must include commands for the primary
-reference source such as a GPS receiver.
-.PP
-The remaining configuration files for all secondary
-servers and clients have the same contents, except for the
-.Ic tos
-command, which is specific for each stratum level.
-For stratum 1 and stratum 2 servers, that command is
-not necessary.
-For stratum 3 and above servers the
-.Cm floor
-value is set to the intended stratum number.
-Thus, all stratum 3 configuration files are identical,
-all stratum 4 files are identical and so forth.
-.PP
-Once operations have stabilized in this scenario,
-the primary servers will find the primary reference source
-and each other, since they both operate at the same
-stratum (1), but not with any secondary server or client,
-since these operate at a higher stratum.
-The secondary
-servers will find the servers at the same stratum level.
-If one of the primary servers loses its GPS receiver,
-it will continue to operate as a client and other clients
-will time out the corresponding association and
-re-associate accordingly.
-.PP
-Some administrators prefer to avoid running
-.Xr ntpd @NTPD_MS@
-continuously and run either
-.Xr ntpdate 8
-or
-.Xr ntpd @NTPD_MS@
-q
-as a cron job.
-In either case the servers must be
-configured in advance and the program fails if none are
-available when the cron job runs.
-A really slick
-application of manycast is with
-.Xr ntpd @NTPD_MS@
-q .
-The program wakes up, scans the local landscape looking
-for the usual suspects, selects the best from among
-the rascals, sets the clock and then departs.
-Servers do not have to be configured in advance and
-all clients throughout the network can have the same
-configuration file.
-.SS Manycast Interactions with Autokey
-Each time a manycast client sends a client mode packet
-to a multicast group address, all manycast servers
-in scope generate a reply including the host name
-and status word.
-The manycast clients then run
-the Autokey protocol, which collects and verifies
-all certificates involved.
-Following the burst interval
-all but three survivors are cast off,
-but the certificates remain in the local cache.
-It often happens that several complete signing trails
-from the client to the primary servers are collected in this way.
-.PP
-About once an hour or less often if the poll interval
-exceeds this, the client regenerates the Autokey key list.
-This is in general transparent in client/server mode.
-However, about once per day the server private value
-used to generate cookies is refreshed along with all
-manycast client associations.
-In this case all
-cryptographic values including certificates is refreshed.
-If a new certificate has been generated since
-the last refresh epoch, it will automatically revoke
-all prior certificates that happen to be in the
-certificate cache.
-At the same time, the manycast
-scheme starts all over from the beginning and
-the expanding ring shrinks to the minimum and increments
-from there while collecting all servers in scope.
-.SS Manycast Options
-.TP
-.BR Xo Ic tos
-.Oo
-.Cm ceiling Ar ceiling |
-.Cm cohort { 0 | 1 } |
-.Cm floor Ar floor |
-.Cm minclock Ar minclock |
-.Cm minsane Ar minsane
-.Oc
-.Xc
-This command affects the clock selection and clustering
-algorithms.
-It can be used to select the quality and
-quantity of peers used to synchronize the system clock
-and is most useful in manycast mode.
-The variables operate
-as follows:
-.in +4
-.ti -4
-.IR Cm ceiling Ar ceiling
-Peers with strata above
-.Cm ceiling
-will be discarded if there are at least
-.Cm minclock
-peers remaining.
-This value defaults to 15, but can be changed
-to any number from 1 to 15.
-.ti -4
-.IR Cm cohort Bro 0 | 1 Brc
-This is a binary flag which enables (0) or disables (1)
-manycast server replies to manycast clients with the same
-stratum level.
-This is useful to reduce implosions where
-large numbers of clients with the same stratum level
-are present.
-The default is to enable these replies.
-.ti -4
-.IR Cm floor Ar floor
-Peers with strata below
-.Cm floor
-will be discarded if there are at least
-.Cm minclock
-peers remaining.
-This value defaults to 1, but can be changed
-to any number from 1 to 15.
-.ti -4
-.IR Cm minclock Ar minclock
-The clustering algorithm repeatedly casts out outlyer
-associations until no more than
-.Cm minclock
-associations remain.
-This value defaults to 3,
-but can be changed to any number from 1 to the number of
-configured sources.
-.ti -4
-.IR Cm minsane Ar minsane
-This is the minimum number of candidates available
-to the clock selection algorithm in order to produce
-one or more truechimers for the clustering algorithm.
-If fewer than this number are available, the clock is
-undisciplined and allowed to run free.
-The default is 1
-for legacy purposes.
-However, according to principles of
-Byzantine agreement,
-.Cm minsane
-should be at least 4 in order to detect and discard
-a single falseticker.
-.in -4
-.TP
-.BR Cm ttl Ar hop ...
-This command specifies a list of TTL values in increasing
-order, up to 8 values can be specified.
-In manycast mode these values are used in turn
-in an expanding-ring search.
-The default is eight
-multiples of 32 starting at 31.
-.SH Reference Clock Support
-The NTP Version 4 daemon supports some three dozen different radio,
-satellite and modem reference clocks plus a special pseudo-clock
-used for backup or when no other clock source is available.
-Detailed descriptions of individual device drivers and options can
-be found in the
-.Qq Reference Clock Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-Additional information can be found in the pages linked
-there, including the
-.Qq Debugging Hints for Reference Clock Drivers
-and
-.Qq How To Write a Reference Clock Driver
-pages
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-In addition, support for a PPS
-signal is available as described in the
-.Qq Pulse-per-second (PPS) Signal Interfacing
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-Many
-drivers support special line discipline/streams modules which can
-significantly improve the accuracy using the driver.
-These are
-described in the
-.Qq Line Disciplines and Streams Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.PP
-A reference clock will generally (though not always) be a radio
-timecode receiver which is synchronized to a source of standard
-time such as the services offered by the NRC in Canada and NIST and
-USNO in the US.
-The interface between the computer and the timecode
-receiver is device dependent, but is usually a serial port.
-A
-device driver specific to each reference clock must be selected and
-compiled in the distribution; however, most common radio, satellite
-and modem clocks are included by default.
-Note that an attempt to
-configure a reference clock when the driver has not been compiled
-or the hardware port has not been appropriately configured results
-in a scalding remark to the system log file, but is otherwise non
-hazardous.
-.PP
-For the purposes of configuration,
-.Xr ntpd @NTPD_MS@
-treats
-reference clocks in a manner analogous to normal NTP peers as much
-as possible.
-Reference clocks are identified by a syntactically
-correct but invalid IP address, in order to distinguish them from
-normal NTP peers.
-Reference clock addresses are of the form
-.Sm off
-.Li 127.127. Ar t . Ar u ,
-.Sm on
-where
-\fIt\fR
-is an integer
-denoting the clock type and
-\fIu\fR
-indicates the unit
-number in the range 0-3.
-While it may seem overkill, it is in fact
-sometimes useful to configure multiple reference clocks of the same
-type, in which case the unit numbers must be unique.
-.PP
-The
-.Ic server
-command is used to configure a reference
-clock, where the
-\fIaddress\fR
-argument in that command
-is the clock address.
-The
-.Cm key ,
-.Cm version
-and
-.Cm ttl
-options are not used for reference clock support.
-The
-.Cm mode
-option is added for reference clock support, as
-described below.
-The
-.Cm prefer
-option can be useful to
-persuade the server to cherish a reference clock with somewhat more
-enthusiasm than other reference clocks or peers.
-Further
-information on this option can be found in the
-.Qq Mitigation Rules and the prefer Keyword
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-page.
-The
-.Cm minpoll
-and
-.Cm maxpoll
-options have
-meaning only for selected clock drivers.
-See the individual clock
-driver document pages for additional information.
-.PP
-The
-.Ic fudge
-command is used to provide additional
-information for individual clock drivers and normally follows
-immediately after the
-.Ic server
-command.
-The
-\fIaddress\fR
-argument specifies the clock address.
-The
-.Cm refid
-and
-.Cm stratum
-options can be used to
-override the defaults for the device.
-There are two optional
-device-dependent time offsets and four flags that can be included
-in the
-.Ic fudge
-command as well.
-.PP
-The stratum number of a reference clock is by default zero.
-Since the
-.Xr ntpd @NTPD_MS@
-daemon adds one to the stratum of each
-peer, a primary server ordinarily displays an external stratum of
-one.
-In order to provide engineered backups, it is often useful to
-specify the reference clock stratum as greater than zero.
-The
-.Cm stratum
-option is used for this purpose.
-Also, in cases
-involving both a reference clock and a pulse-per-second (PPS)
-discipline signal, it is useful to specify the reference clock
-identifier as other than the default, depending on the driver.
-The
-.Cm refid
-option is used for this purpose.
-Except where noted,
-these options apply to all clock drivers.
-.SS Reference Clock Commands
-.TP
-.BR Xo Ic server
-.Sm off
-.Li 127.127. Ar t . Ar u
-.Sm on
-[ "\fIprefer\fR" ]
-[ "\fImode\fR" "\fIint\fR" ]
-[ "\fIminpoll\fR" "\fIint\fR" ]
-[ "\fImaxpoll\fR" "\fIint\fR" ]
-.Xc
-This command can be used to configure reference clocks in
-special ways.
-The options are interpreted as follows:
-.in +4
-.ti -4
-.IR Cm prefer
-Marks the reference clock as preferred.
-All other things being
-equal, this host will be chosen for synchronization among a set of
-correctly operating hosts.
-See the
-.Qq Mitigation Rules and the prefer Keyword
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-for further information.
-.ti -4
-.IR Cm mode Ar int
-Specifies a mode number which is interpreted in a
-device-specific fashion.
-For instance, it selects a dialing
-protocol in the ACTS driver and a device subtype in the
-parse
-drivers.
-.ti -4
-.IR Cm minpoll Ar int
-.ti -4
-.IR Cm maxpoll Ar int
-These options specify the minimum and maximum polling interval
-for reference clock messages, as a power of 2 in seconds
-For
-most directly connected reference clocks, both
-.Cm minpoll
-and
-.Cm maxpoll
-default to 6 (64 s).
-For modem reference clocks,
-.Cm minpoll
-defaults to 10 (17.1 m) and
-.Cm maxpoll
-defaults to 14 (4.5 h).
-The allowable range is 4 (16 s) to 17 (36.4 h) inclusive.
-.in -4
-.TP
-.BR Xo Ic fudge
-.Sm off
-.Li 127.127. Ar t . Ar u
-.Sm on
-[ "\fItime1\fR" "\fIsec\fR" ]
-[ "\fItime2\fR" "\fIsec\fR" ]
-[ "\fIstratum\fR" "\fIint\fR" ]
-[ "\fIrefid\fR" "\fIstring\fR" ]
-[ "\fImode\fR" "\fIint\fR" ]
-[ "\fIflag1\fR" "\fI0\fR" \&| "\fI1\fR" ]
-[ "\fIflag2\fR" "\fI0\fR" \&| "\fI1\fR" ]
-[ "\fIflag3\fR" "\fI0\fR" \&| "\fI1\fR" ]
-[ "\fIflag4\fR" "\fI0\fR" \&| "\fI1\fR" ]
-.Xc
-This command can be used to configure reference clocks in
-special ways.
-It must immediately follow the
-.Ic server
-command which configures the driver.
-Note that the same capability
-is possible at run time using the
-.Xr ntpdc @NTPDC_MS@
-program.
-The options are interpreted as
-follows:
-.in +4
-.ti -4
-.IR Cm time1 Ar sec
-Specifies a constant to be added to the time offset produced by
-the driver, a fixed-point decimal number in seconds.
-This is used
-as a calibration constant to adjust the nominal time offset of a
-particular clock to agree with an external standard, such as a
-precision PPS signal.
-It also provides a way to correct a
-systematic error or bias due to serial port or operating system
-latencies, different cable lengths or receiver internal delay.
-The
-specified offset is in addition to the propagation delay provided
-by other means, such as internal DIPswitches.
-Where a calibration
-for an individual system and driver is available, an approximate
-correction is noted in the driver documentation pages.
-Note: in order to facilitate calibration when more than one
-radio clock or PPS signal is supported, a special calibration
-feature is available.
-It takes the form of an argument to the
-.Ic enable
-command described in
-.Sx Miscellaneous Options
-page and operates as described in the
-.Qq Reference Clock Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.ti -4
-.IR Cm time2 Ar secs
-Specifies a fixed-point decimal number in seconds, which is
-interpreted in a driver-dependent way.
-See the descriptions of
-specific drivers in the
-.Qq Reference Clock Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.ti -4
-.IR Cm stratum Ar int
-Specifies the stratum number assigned to the driver, an integer
-between 0 and 15.
-This number overrides the default stratum number
-ordinarily assigned by the driver itself, usually zero.
-.ti -4
-.IR Cm refid Ar string
-Specifies an ASCII string of from one to four characters which
-defines the reference identifier used by the driver.
-This string
-overrides the default identifier ordinarily assigned by the driver
-itself.
-.ti -4
-.IR Cm mode Ar int
-Specifies a mode number which is interpreted in a
-device-specific fashion.
-For instance, it selects a dialing
-protocol in the ACTS driver and a device subtype in the
-parse
-drivers.
-.ti -4
-.IR Cm flag1 Cm 0 \&| Cm 1
-.ti -4
-.IR Cm flag2 Cm 0 \&| Cm 1
-.ti -4
-.IR Cm flag3 Cm 0 \&| Cm 1
-.ti -4
-.IR Cm flag4 Cm 0 \&| Cm 1
-These four flags are used for customizing the clock driver.
-The
-interpretation of these values, and whether they are used at all,
-is a function of the particular clock driver.
-However, by
-convention
-.Cm flag4
-is used to enable recording monitoring
-data to the
-.Cm clockstats
-file configured with the
-.Ic filegen
-command.
-Further information on the
-.Ic filegen
-command can be found in
-.Sx Monitoring Options .
-.in -4
-.SH Miscellaneous Options
-.TP
-.BR Ic broadcastdelay Ar seconds
-The broadcast and multicast modes require a special calibration
-to determine the network delay between the local and remote
-servers.
-Ordinarily, this is done automatically by the initial
-protocol exchanges between the client and server.
-In some cases,
-the calibration procedure may fail due to network or server access
-controls, for example.
-This command specifies the default delay to
-be used under these circumstances.
-Typically (for Ethernet), a
-number between 0.003 and 0.007 seconds is appropriate.
-The default
-when this command is not used is 0.004 seconds.
-.TP
-.BR Ic calldelay Ar delay
-This option controls the delay in seconds between the first and second
-packets sent in burst or iburst mode to allow additional time for a modem
-or ISDN call to complete.
-.TP
-.BR Ic driftfile Ar driftfile
-This command specifies the complete path and name of the file used to
-record the frequency of the local clock oscillator.
-This is the same
-operation as the
-f
-command line option.
-If the file exists, it is read at
-startup in order to set the initial frequency and then updated once per
-hour with the current frequency computed by the daemon.
-If the file name is
-specified, but the file itself does not exist, the starts with an initial
-frequency of zero and creates the file when writing it for the first time.
-If this command is not given, the daemon will always start with an initial
-frequency of zero.
-.PP
-The file format consists of a single line containing a single
-floating point number, which records the frequency offset measured
-in parts-per-million (PPM).
-The file is updated by first writing
-the current drift value into a temporary file and then renaming
-this file to replace the old version.
-This implies that
-.Xr ntpd @NTPD_MS@
-must have write permission for the directory the
-drift file is located in, and that file system links, symbolic or
-otherwise, should be avoided.
-.TP
-.BR Xo Ic enable
-.Oo
-.Cm auth | Cm bclient |
-.Cm calibrate | Cm kernel |
-.Cm monitor | Cm ntp |
-.Cm pps | Cm stats
-.Oc
-.Xc
-.TP
-.BR Xo Ic disable
-.Oo
-.Cm auth | Cm bclient |
-.Cm calibrate | Cm kernel |
-.Cm monitor | Cm ntp |
-.Cm pps | Cm stats
-.Oc
-.Xc
-Provides a way to enable or disable various server options.
-Flags not mentioned are unaffected.
-Note that all of these flags
-can be controlled remotely using the
-.Xr ntpdc @NTPDC_MS@
-utility program.
-.in +4
-.ti -4
-.IR Cm auth
-Enables the server to synchronize with unconfigured peers only if the
-peer has been correctly authenticated using either public key or
-private key cryptography.
-The default for this flag is
-.Ic enable .
-.ti -4
-.IR Cm bclient
-Enables the server to listen for a message from a broadcast or
-multicast server, as in the
-.Ic multicastclient
-command with default
-address.
-The default for this flag is
-.Ic disable .
-.ti -4
-.IR Cm calibrate
-Enables the calibrate feature for reference clocks.
-The default for
-this flag is
-.Ic disable .
-.ti -4
-.IR Cm kernel
-Enables the kernel time discipline, if available.
-The default for this
-flag is
-.Ic enable
-if support is available, otherwise
-.Ic disable .
-.ti -4
-.IR Cm monitor
-Enables the monitoring facility.
-See the
-.Xr ntpdc @NTPDC_MS@
-program
-and the
-.Ic monlist
-command or further information.
-The
-default for this flag is
-.Ic enable .
-.ti -4
-.IR Cm ntp
-Enables time and frequency discipline.
-In effect, this switch opens and
-closes the feedback loop, which is useful for testing.
-The default for
-this flag is
-.Ic enable .
-.ti -4
-.IR Cm pps
-Enables the pulse-per-second (PPS) signal when frequency and time is
-disciplined by the precision time kernel modifications.
-See the
-.Qq A Kernel Model for Precision Timekeeping
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-page for further information.
-The default for this flag is
-.Ic disable .
-.ti -4
-.IR Cm stats
-Enables the statistics facility.
-See the
-.Sx Monitoring Options
-section for further information.
-The default for this flag is
-.Ic disable .
-.in -4
-.TP
-.BR Ic includefile Ar includefile
-This command allows additional configuration commands
-to be included from a separate file.
-Include files may
-be nested to a depth of five; upon reaching the end of any
-include file, command processing resumes in the previous
-configuration file.
-This option is useful for sites that run
-.Xr ntpd @NTPD_MS@
-on multiple hosts, with (mostly) common options (e.g., a
-restriction list).
-.TP
-.BR Ic logconfig Ar configkeyword
-This command controls the amount and type of output written to
-the system
-.Xr syslog 3
-facility or the alternate
-.Ic logfile
-log file.
-By default, all output is turned on.
-All
-\fIconfigkeyword\fR
-keywords can be prefixed with
-.Ql = ,
-.Ql +
-and
-.Ql - ,
-where
-.Ql =
-sets the
-.Xr syslog 3
-priority mask,
-.Ql +
-adds and
-.Ql -
-removes
-messages.
-.Xr syslog 3
-messages can be controlled in four
-classes
-.Po
-.Cm clock ,
-.Cm peer ,
-.Cm sys
-and
-.Cm sync
-.Pc .
-Within these classes four types of messages can be
-controlled: informational messages
-.Po
-.Cm info
-.Pc ,
-event messages
-.Po
-.Cm events
-.Pc ,
-statistics messages
-.Po
-.Cm statistics
-.Pc
-and
-status messages
-.Po
-.Cm status
-.Pc .
-.PP
-Configuration keywords are formed by concatenating the message class with
-the event class.
-The
-.Cm all
-prefix can be used instead of a message class.
-A
-message class may also be followed by the
-.Cm all
-keyword to enable/disable all
-messages of the respective message class.Thus, a minimal log configuration
-could look like this:
-.br
-.in +4
-.nf
-logconfig =syncstatus +sysevents
-.in -4
-.fi
-.PP
-This would just list the synchronizations state of
-.Xr ntpd @NTPD_MS@
-and the major system events.
-For a simple reference server, the
-following minimum message configuration could be useful:
-.br
-.in +4
-.nf
-logconfig =syncall +clockall
-.in -4
-.fi
-.PP
-This configuration will list all clock information and
-synchronization information.
-All other events and messages about
-peers, system events and so on is suppressed.
-.TP
-.BR Ic logfile Ar logfile
-This command specifies the location of an alternate log file to
-be used instead of the default system
-.Xr syslog 3
-facility.
-This is the same operation as the -l command line option.
-.TP
-.BR Ic setvar Ar variable Op Cm default
-This command adds an additional system variable.
-These
-variables can be used to distribute additional information such as
-the access policy.
-If the variable of the form
-.Sm off
-.Va name = Ar value
-.Sm on
-is followed by the
-.Cm default
-keyword, the
-variable will be listed as part of the default system variables
-.Po
-.Xr ntpq @NTPQ_MS@
-.Ic rv
-command
-.Pc ) .
-These additional variables serve
-informational purposes only.
-They are not related to the protocol
-other that they can be listed.
-The known protocol variables will
-always override any variables defined via the
-.Ic setvar
-mechanism.
-There are three special variables that contain the names
-of all variable of the same group.
-The
-.Va sys_var_list
-holds
-the names of all system variables.
-The
-.Va peer_var_list
-holds
-the names of all peer variables and the
-.Va clock_var_list
-holds the names of the reference clock variables.
-.TP
-.BR Xo Ic tinker
-.Oo
-.Cm allan Ar allan |
-.Cm dispersion Ar dispersion |
-.Cm freq Ar freq |
-.Cm huffpuff Ar huffpuff |
-.Cm panic Ar panic |
-.Cm step Ar srep |
-.Cm stepout Ar stepout
-.Oc
-.Xc
-This command can be used to alter several system variables in
-very exceptional circumstances.
-It should occur in the
-configuration file before any other configuration options.
-The
-default values of these variables have been carefully optimized for
-a wide range of network speeds and reliability expectations.
-In
-general, they interact in intricate ways that are hard to predict
-and some combinations can result in some very nasty behavior.
-Very
-rarely is it necessary to change the default values; but, some
-folks cannot resist twisting the knobs anyway and this command is
-for them.
-Emphasis added: twisters are on their own and can expect
-no help from the support group.
-.PP
-The variables operate as follows:
-.in +4
-.ti -4
-.IR Cm allan Ar allan
-The argument becomes the new value for the minimum Allan
-intercept, which is a parameter of the PLL/FLL clock discipline
-algorithm.
-The value in log2 seconds defaults to 7 (1024 s), which is also the lower
-limit.
-.ti -4
-.IR Cm dispersion Ar dispersion
-The argument becomes the new value for the dispersion increase rate,
-normally .000015 s/s.
-.ti -4
-.IR Cm freq Ar freq
-The argument becomes the initial value of the frequency offset in
-parts-per-million.
-This overrides the value in the frequency file, if
-present, and avoids the initial training state if it is not.
-.ti -4
-.IR Cm huffpuff Ar huffpuff
-The argument becomes the new value for the experimental
-huff-n'-puff filter span, which determines the most recent interval
-the algorithm will search for a minimum delay.
-The lower limit is
-900 s (15 m), but a more reasonable value is 7200 (2 hours).
-There
-is no default, since the filter is not enabled unless this command
-is given.
-.ti -4
-.IR Cm panic Ar panic
-The argument is the panic threshold, normally 1000 s.
-If set to zero,
-the panic sanity check is disabled and a clock offset of any value will
-be accepted.
-.ti -4
-.IR Cm step Ar step
-The argument is the step threshold, which by default is 0.128 s.
-It can
-be set to any positive number in seconds.
-If set to zero, step
-adjustments will never occur.
-Note: The kernel time discipline is
-disabled if the step threshold is set to zero or greater than the
-default.
-.ti -4
-.IR Cm stepout Ar stepout
-The argument is the stepout timeout, which by default is 900 s.
-It can
-be set to any positive number in seconds.
-If set to zero, the stepout
-pulses will not be suppressed.
-.in -4
-.TP
-.BR Xo Ic trap Ar host_address
-[ "\fIport\fR" "\fIport_number\fR" ]
-[ "\fIinterface\fR" "\fIinterface_address\fR" ]
-.Xc
-This command configures a trap receiver at the given host
-address and port number for sending messages with the specified
-local interface address.
-If the port number is unspecified, a value
-of 18447 is used.
-If the interface address is not specified, the
-message is sent with a source address of the local interface the
-message is sent through.
-Note that on a multihomed host the
-interface used may vary from time to time with routing changes.
-.PP
-The trap receiver will generally log event messages and other
-information from the server in a log file.
-While such monitor
-programs may also request their own trap dynamically, configuring a
-trap receiver will ensure that no messages are lost when the server
-is started.
-.TP
-.BR Cm hop Ar ...
-This command specifies a list of TTL values in increasing order, up to 8
-values can be specified.
-In manycast mode these values are used in turn in
-an expanding-ring search.
-The default is eight multiples of 32 starting at
-31.
.SH FILES
-.TP
-.BR Pa /etc/ntp.conf
-the default name of the configuration file
-.TP
-.BR Pa ntp.keys
-private MD5 keys
-.TP
-.BR Pa ntpkey
-RSA private key
-.TP
-.BR Pa ntpkey_ Ns Ar host
-RSA public key
-.TP
-.BR Pa ntp_dh
-Diffie-Hellman agreement parameters
.SH "SEE ALSO"
-.SH SEE ALSO
-.Xr ntpd @NTPD_MS@ ,
-.Xr ntpdc @NTPDC_MS@ ,
-.Xr ntpq @NTPQ_MS@
-.PP
-In addition to the manual pages provided,
-comprehensive documentation is available on the world wide web
-at
-.Li http://www.ntp.org/ .
-A snapshot of this documentation is available in HTML format in
-.Pa /usr/share/doc/ntp .
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 4)
-.%O RFC5905
-.Re
.SH "AUTHORS"
The University of Delaware
.SH "COPYRIGHT"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.SH BUGS
-The syntax checking is not picky; some combinations of
-ridiculous and even hilarious options and modes may not be
-detected.
-.PP
-The
-.Pa ntpkey_ Ns Ar host
-files are really digital
-certificates.
-These should be obtained via secure directory
-services when they become universally available.Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
+Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.SH NOTES
-This document is derived from FreeBSD.
.PP
This manual page was \fIAutoGen\fP-erated from the \fBntp.conf\fP
option definitions.
-.Dd December 5 2012
+.Dd December 6 2012
.Dt NTP_CONF 5 File Formats
-.Os FreeBSD 6.4-STABLE
+.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp.mdoc)
.\"
-.\" It has been AutoGen-ed December 5, 2012 at 10:45:51 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:25 AM by AutoGen 5.16.2
.\" From the definitions ntp.conf.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
All arguments must be options.
.Pp
.Sh DESCRIPTION
-The
-.Nm
-configuration file is read at initial startup by the
-.Xr ntpd @NTPD_MS@
-daemon in order to specify the synchronization sources,
-modes and other related information.
-Usually, it is installed in the
-.Pa /etc
-directory,
-but could be installed elsewhere
-(see the daemon's
-.Fl c
-command line option).
-.Pp
-The file format is similar to other
-.Ux
-configuration files.
-Comments begin with a
-.Ql #
-character and extend to the end of the line;
-blank lines are ignored.
-Configuration commands consist of an initial keyword
-followed by a list of arguments,
-some of which may be optional, separated by whitespace.
-Commands may not be continued over multiple lines.
-Arguments may be host names,
-host addresses written in numeric, dotted-quad form,
-integers, floating point numbers (when specifying times in seconds)
-and text strings.
-.Pp
-The rest of this page describes the configuration and control options.
-The
-.Qq Notes on Configuring NTP and Setting up a NTP Subnet
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-contains an extended discussion of these options.
-In addition to the discussion of general
-.Sx Configuration Options ,
-there are sections describing the following supported functionality
-and the options used to control it:
-.Bl -bullet -offset indent
-.It
-.Sx Authentication Support
-.It
-.Sx Monitoring Support
-.It
-.Sx Access Control Support
-.It
-.Sx Automatic NTP Configuration Options
-.It
-.Sx Reference Clock Support
-.It
-.Sx Miscellaneous Options
-.El
-.Pp
-Following these is a section describing
-.Sx Miscellaneous Options .
-While there is a rich set of options available,
-the only required option is one or more
-.Ic pool ,
-.Ic server ,
-.Ic peer ,
-.Ic broadcast
-or
-.Ic manycastclient
-commands.
-.Sh Configuration Support
-Following is a description of the configuration commands in
-NTPv4.
-These commands have the same basic functions as in NTPv3 and
-in some cases new functions and new arguments.
-There are two
-classes of commands, configuration commands that configure a
-persistent association with a remote server or peer or reference
-clock, and auxiliary commands that specify environmental variables
-that control various related operations.
-.Ss Configuration Commands
-The various modes are determined by the command keyword and the
-type of the required IP address.
-Addresses are classed by type as
-(s) a remote server or peer (IPv4 class A, B and C), (b) the
-broadcast address of a local interface, (m) a multicast address (IPv4
-class D), or (r) a reference clock address (127.127.x.x).
-Note that
-only those options applicable to each command are listed below.
-Use
-of options not listed may not be caught as an error, but may result
-in some weird and even destructive behavior.
-.Pp
-If the Basic Socket Interface Extensions for IPv6 (RFC-2553)
-is detected, support for the IPv6 address family is generated
-in addition to the default support of the IPv4 address family.
-In a few cases, including the reslist billboard generated
-by ntpdc, IPv6 addresses are automatically generated.
-IPv6 addresses can be identified by the presence of colons
-.Dq \&:
-in the address field.
-IPv6 addresses can be used almost everywhere where
-IPv4 addresses can be used,
-with the exception of reference clock addresses,
-which are always IPv4.
-.Pp
-Note that in contexts where a host name is expected, a
-.Fl 4
-qualifier preceding
-the host name forces DNS resolution to the IPv4 namespace,
-while a
-.Fl 6
-qualifier forces DNS resolution to the IPv6 namespace.
-See IPv6 references for the
-equivalent classes for that address family.
-.Bl -tag -width indent
-.It Xo Ic pool Ar address
-.Op Cm burst
-.Op Cm iburst
-.Op Cm version Ar version
-.Op Cm prefer
-.Op Cm minpoll Ar minpoll
-.Op Cm maxpoll Ar maxpoll
-.Xc
-.It Xo Ic server Ar address
-.Op Cm key Ar key \&| Cm autokey
-.Op Cm burst
-.Op Cm iburst
-.Op Cm version Ar version
-.Op Cm prefer
-.Op Cm minpoll Ar minpoll
-.Op Cm maxpoll Ar maxpoll
-.Xc
-.It Xo Ic peer Ar address
-.Op Cm key Ar key \&| Cm autokey
-.Op Cm version Ar version
-.Op Cm prefer
-.Op Cm minpoll Ar minpoll
-.Op Cm maxpoll Ar maxpoll
-.Xc
-.It Xo Ic broadcast Ar address
-.Op Cm key Ar key \&| Cm autokey
-.Op Cm version Ar version
-.Op Cm prefer
-.Op Cm minpoll Ar minpoll
-.Op Cm ttl Ar ttl
-.Xc
-.It Xo Ic manycastclient Ar address
-.Op Cm key Ar key \&| Cm autokey
-.Op Cm version Ar version
-.Op Cm prefer
-.Op Cm minpoll Ar minpoll
-.Op Cm maxpoll Ar maxpoll
-.Op Cm ttl Ar ttl
-.Xc
-.El
-.Pp
-These five commands specify the time server name or address to
-be used and the mode in which to operate.
-The
-.Ar address
-can be
-either a DNS name or an IP address in dotted-quad notation.
-Additional information on association behavior can be found in the
-.Qq Association Management
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.Bl -tag -width indent
-.It Ic pool
-For type s addresses, this command mobilizes a persistent
-client mode association with a number of remote servers.
-In this mode the local clock can synchronized to the
-remote server, but the remote server can never be synchronized to
-the local clock.
-.It Ic server
-For type s and r addresses, this command mobilizes a persistent
-client mode association with the specified remote server or local
-radio clock.
-In this mode the local clock can synchronized to the
-remote server, but the remote server can never be synchronized to
-the local clock.
-This command should
-.Em not
-be used for type
-b or m addresses.
-.It Ic peer
-For type s addresses (only), this command mobilizes a
-persistent symmetric-active mode association with the specified
-remote peer.
-In this mode the local clock can be synchronized to
-the remote peer or the remote peer can be synchronized to the local
-clock.
-This is useful in a network of servers where, depending on
-various failure scenarios, either the local or remote peer may be
-the better source of time.
-This command should NOT be used for type
-b, m or r addresses.
-.It Ic broadcast
-For type b and m addresses (only), this
-command mobilizes a persistent broadcast mode association.
-Multiple
-commands can be used to specify multiple local broadcast interfaces
-(subnets) and/or multiple multicast groups.
-Note that local
-broadcast messages go only to the interface associated with the
-subnet specified, but multicast messages go to all interfaces.
-In broadcast mode the local server sends periodic broadcast
-messages to a client population at the
-.Ar address
-specified, which is usually the broadcast address on (one of) the
-local network(s) or a multicast address assigned to NTP.
-The IANA
-has assigned the multicast group address IPv4 224.0.1.1 and
-IPv6 ff05::101 (site local) exclusively to
-NTP, but other nonconflicting addresses can be used to contain the
-messages within administrative boundaries.
-Ordinarily, this
-specification applies only to the local server operating as a
-sender; for operation as a broadcast client, see the
-.Ic broadcastclient
-or
-.Ic multicastclient
-commands
-below.
-.It Ic manycastclient
-For type m addresses (only), this command mobilizes a
-manycast client mode association for the multicast address
-specified.
-In this case a specific address must be supplied which
-matches the address used on the
-.Ic manycastserver
-command for
-the designated manycast servers.
-The NTP multicast address
-224.0.1.1 assigned by the IANA should NOT be used, unless specific
-means are taken to avoid spraying large areas of the Internet with
-these messages and causing a possibly massive implosion of replies
-at the sender.
-The
-.Ic manycastserver
-command specifies that the local server
-is to operate in client mode with the remote servers that are
-discovered as the result of broadcast/multicast messages.
-The
-client broadcasts a request message to the group address associated
-with the specified
-.Ar address
-and specifically enabled
-servers respond to these messages.
-The client selects the servers
-providing the best time and continues as with the
-.Ic server
-command.
-The remaining servers are discarded as if never
-heard.
-.El
-.Pp
-Options:
-.Bl -tag -width indent
-.It Cm autokey
-All packets sent to and received from the server or peer are to
-include authentication fields encrypted using the autokey scheme
-described in
-.Sx Authentication Options .
-.It Cm burst
-when the server is reachable, send a burst of eight packets
-instead of the usual one.
-The packet spacing is normally 2 s;
-however, the spacing between the first and second packets
-can be changed with the calldelay command to allow
-additional time for a modem or ISDN call to complete.
-This is designed to improve timekeeping quality
-with the
-.Ic server
-command and s addresses.
-.It Cm iburst
-When the server is unreachable, send a burst of eight packets
-instead of the usual one.
-The packet spacing is normally 2 s;
-however, the spacing between the first two packets can be
-changed with the calldelay command to allow
-additional time for a modem or ISDN call to complete.
-This is designed to speed the initial synchronization
-acquisition with the
-.Ic server
-command and s addresses and when
-.Xr ntpd @NTPD_MS@
-is started with the
-.Fl q
-option.
-.It Cm key Ar key
-All packets sent to and received from the server or peer are to
-include authentication fields encrypted using the specified
-.Ar key
-identifier with values from 1 to 65534, inclusive.
-The
-default is to include no encryption field.
-.It Cm minpoll Ar minpoll
-.It Cm maxpoll Ar maxpoll
-These options specify the minimum and maximum poll intervals
-for NTP messages, as a power of 2 in seconds
-The maximum poll
-interval defaults to 10 (1,024 s), but can be increased by the
-.Cm maxpoll
-option to an upper limit of 17 (36.4 h).
-The
-minimum poll interval defaults to 6 (64 s), but can be decreased by
-the
-.Cm minpoll
-option to a lower limit of 4 (16 s).
-.It Cm noselect
-Marks the server as unused, except for display purposes.
-The server is discarded by the selection algroithm.
-.It Cm prefer
-Marks the server as preferred.
-All other things being equal,
-this host will be chosen for synchronization among a set of
-correctly operating hosts.
-See the
-.Qq Mitigation Rules and the prefer Keyword
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-for further information.
-.It Cm ttl Ar ttl
-This option is used only with broadcast server and manycast
-client modes.
-It specifies the time-to-live
-.Ar ttl
-to
-use on broadcast server and multicast server and the maximum
-.Ar ttl
-for the expanding ring search with manycast
-client packets.
-Selection of the proper value, which defaults to
-127, is something of a black art and should be coordinated with the
-network administrator.
-.It Cm version Ar version
-Specifies the version number to be used for outgoing NTP
-packets.
-Versions 1-4 are the choices, with version 4 the
-default.
-.El
-.Ss Auxiliary Commands
-.Bl -tag -width indent
-.It Ic broadcastclient
-This command enables reception of broadcast server messages to
-any local interface (type b) address.
-Upon receiving a message for
-the first time, the broadcast client measures the nominal server
-propagation delay using a brief client/server exchange with the
-server, then enters the broadcast client mode, in which it
-synchronizes to succeeding broadcast messages.
-Note that, in order
-to avoid accidental or malicious disruption in this mode, both the
-server and client should operate using symmetric-key or public-key
-authentication as described in
-.Sx Authentication Options .
-.It Ic manycastserver Ar address ...
-This command enables reception of manycast client messages to
-the multicast group address(es) (type m) specified.
-At least one
-address is required, but the NTP multicast address 224.0.1.1
-assigned by the IANA should NOT be used, unless specific means are
-taken to limit the span of the reply and avoid a possibly massive
-implosion at the original sender.
-Note that, in order to avoid
-accidental or malicious disruption in this mode, both the server
-and client should operate using symmetric-key or public-key
-authentication as described in
-.Sx Authentication Options .
-.It Ic multicastclient Ar address ...
-This command enables reception of multicast server messages to
-the multicast group address(es) (type m) specified.
-Upon receiving
-a message for the first time, the multicast client measures the
-nominal server propagation delay using a brief client/server
-exchange with the server, then enters the broadcast client mode, in
-which it synchronizes to succeeding multicast messages.
-Note that,
-in order to avoid accidental or malicious disruption in this mode,
-both the server and client should operate using symmetric-key or
-public-key authentication as described in
-.Sx Authentication Options .
-.El
-.Sh Authentication Support
-Authentication support allows the NTP client to verify that the
-server is in fact known and trusted and not an intruder intending
-accidentally or on purpose to masquerade as that server.
-The NTPv3
-specification RFC-1305 defines a scheme which provides
-cryptographic authentication of received NTP packets.
-Originally,
-this was done using the Data Encryption Standard (DES) algorithm
-operating in Cipher Block Chaining (CBC) mode, commonly called
-DES-CBC.
-Subsequently, this was replaced by the RSA Message Digest
-5 (MD5) algorithm using a private key, commonly called keyed-MD5.
-Either algorithm computes a message digest, or one-way hash, which
-can be used to verify the server has the correct private key and
-key identifier.
-.Pp
-NTPv4 retains the NTPv3 scheme, properly described as symmetric key
-cryptography and, in addition, provides a new Autokey scheme
-based on public key cryptography.
-Public key cryptography is generally considered more secure
-than symmetric key cryptography, since the security is based
-on a private value which is generated by each server and
-never revealed.
-With Autokey all key distribution and
-management functions involve only public values, which
-considerably simplifies key distribution and storage.
-Public key management is based on X.509 certificates,
-which can be provided by commercial services or
-produced by utility programs in the OpenSSL software library
-or the NTPv4 distribution.
-.Pp
-While the algorithms for symmetric key cryptography are
-included in the NTPv4 distribution, public key cryptography
-requires the OpenSSL software library to be installed
-before building the NTP distribution.
-Directions for doing that
-are on the Building and Installing the Distribution page.
-.Pp
-Authentication is configured separately for each association
-using the
-.Cm key
-or
-.Cm autokey
-subcommand on the
-.Ic peer ,
-.Ic server ,
-.Ic broadcast
-and
-.Ic manycastclient
-configuration commands as described in
-.Sx Configuration Options
-page.
-The authentication
-options described below specify the locations of the key files,
-if other than default, which symmetric keys are trusted
-and the interval between various operations, if other than default.
-.Pp
-Authentication is always enabled,
-although ineffective if not configured as
-described below.
-If a NTP packet arrives
-including a message authentication
-code (MAC), it is accepted only if it
-passes all cryptographic checks.
-The
-checks require correct key ID, key value
-and message digest.
-If the packet has
-been modified in any way or replayed
-by an intruder, it will fail one or more
-of these checks and be discarded.
-Furthermore, the Autokey scheme requires a
-preliminary protocol exchange to obtain
-the server certificate, verify its
-credentials and initialize the protocol
-.Pp
-The
-.Cm auth
-flag controls whether new associations or
-remote configuration commands require cryptographic authentication.
-This flag can be set or reset by the
-.Ic enable
-and
-.Ic disable
-commands and also by remote
-configuration commands sent by a
-.Xr ntpdc @NTPDC_MS@
-program running in
-another machine.
-If this flag is enabled, which is the default
-case, new broadcast client and symmetric passive associations and
-remote configuration commands must be cryptographically
-authenticated using either symmetric key or public key cryptography.
-If this
-flag is disabled, these operations are effective
-even if not cryptographic
-authenticated.
-It should be understood
-that operating with the
-.Ic auth
-flag disabled invites a significant vulnerability
-where a rogue hacker can
-masquerade as a falseticker and seriously
-disrupt system timekeeping.
-It is
-important to note that this flag has no purpose
-other than to allow or disallow
-a new association in response to new broadcast
-and symmetric active messages
-and remote configuration commands and, in particular,
-the flag has no effect on
-the authentication process itself.
-.Pp
-An attractive alternative where multicast support is available
-is manycast mode, in which clients periodically troll
-for servers as described in the
-.Sx Automatic NTP Configuration Options
-page.
-Either symmetric key or public key
-cryptographic authentication can be used in this mode.
-The principle advantage
-of manycast mode is that potential servers need not be
-configured in advance,
-since the client finds them during regular operation,
-and the configuration
-files for all clients can be identical.
-.Pp
-The security model and protocol schemes for
-both symmetric key and public key
-cryptography are summarized below;
-further details are in the briefings, papers
-and reports at the NTP project page linked from
-.Li http://www.ntp.org/ .
-.Ss Symmetric-Key Cryptography
-The original RFC-1305 specification allows any one of possibly
-65,534 keys, each distinguished by a 32-bit key identifier, to
-authenticate an association.
-The servers and clients involved must
-agree on the key and key identifier to
-authenticate NTP packets.
-Keys and
-related information are specified in a key
-file, usually called
-.Pa ntp.keys ,
-which must be distributed and stored using
-secure means beyond the scope of the NTP protocol itself.
-Besides the keys used
-for ordinary NTP associations,
-additional keys can be used as passwords for the
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-utility programs.
-.Pp
-When
-.Xr ntpd @NTPD_MS@
-is first started, it reads the key file specified in the
-.Ic keys
-configuration command and installs the keys
-in the key cache.
-However,
-individual keys must be activated with the
-.Ic trusted
-command before use.
-This
-allows, for instance, the installation of possibly
-several batches of keys and
-then activating or deactivating each batch
-remotely using
-.Xr ntpdc @NTPDC_MS@ .
-This also provides a revocation capability that can be used
-if a key becomes compromised.
-The
-.Ic requestkey
-command selects the key used as the password for the
-.Xr ntpdc @NTPDC_MS@
-utility, while the
-.Ic controlkey
-command selects the key used as the password for the
-.Xr ntpq @NTPQ_MS@
-utility.
-.Ss Public Key Cryptography
-NTPv4 supports the original NTPv3 symmetric key scheme
-described in RFC-1305 and in addition the Autokey protocol,
-which is based on public key cryptography.
-The Autokey Version 2 protocol described on the Autokey Protocol
-page verifies packet integrity using MD5 message digests
-and verifies the source with digital signatures and any of several
-digest/signature schemes.
-Optional identity schemes described on the Identity Schemes
-page and based on cryptographic challenge/response algorithms
-are also available.
-Using all of these schemes provides strong security against
-replay with or without modification, spoofing, masquerade
-and most forms of clogging attacks.
-.\" .Pp
-.\" The cryptographic means necessary for all Autokey operations
-.\" is provided by the OpenSSL software library.
-.\" This library is available from http://www.openssl.org/
-.\" and can be installed using the procedures outlined
-.\" in the Building and Installing the Distribution page.
-.\" Once installed,
-.\" the configure and build
-.\" process automatically detects the library and links
-.\" the library routines required.
-.Pp
-The Autokey protocol has several modes of operation
-corresponding to the various NTP modes supported.
-Most modes use a special cookie which can be
-computed independently by the client and server,
-but encrypted in transmission.
-All modes use in addition a variant of the S-KEY scheme,
-in which a pseudo-random key list is generated and used
-in reverse order.
-These schemes are described along with an executive summary,
-current status, briefing slides and reading list on the
-.Sx Autonomous Authentication
-page.
-.Pp
-The specific cryptographic environment used by Autokey servers
-and clients is determined by a set of files
-and soft links generated by the
-.Xr ntp-keygen 1ntpkeygenmdoc
-program.
-This includes a required host key file,
-required certificate file and optional sign key file,
-leapsecond file and identity scheme files.
-The
-digest/signature scheme is specified in the X.509 certificate
-along with the matching sign key.
-There are several schemes
-available in the OpenSSL software library, each identified
-by a specific string such as
-.Cm md5WithRSAEncryption ,
-which stands for the MD5 message digest with RSA
-encryption scheme.
-The current NTP distribution supports
-all the schemes in the OpenSSL library, including
-those based on RSA and DSA digital signatures.
-.Pp
-NTP secure groups can be used to define cryptographic compartments
-and security hierarchies.
-It is important that every host
-in the group be able to construct a certificate trail to one
-or more trusted hosts in the same group.
-Each group
-host runs the Autokey protocol to obtain the certificates
-for all hosts along the trail to one or more trusted hosts.
-This requires the configuration file in all hosts to be
-engineered so that, even under anticipated failure conditions,
-the NTP subnet will form such that every group host can find
-a trail to at least one trusted host.
-.Ss Naming and Addressing
-It is important to note that Autokey does not use DNS to
-resolve addresses, since DNS can't be completely trusted
-until the name servers have synchronized clocks.
-The cryptographic name used by Autokey to bind the host identity
-credentials and cryptographic values must be independent
-of interface, network and any other naming convention.
-The name appears in the host certificate in either or both
-the subject and issuer fields, so protection against
-DNS compromise is essential.
-.Pp
-By convention, the name of an Autokey host is the name returned
-by the Unix
-.Xr gethostname 2
-system call or equivalent in other systems.
-By the system design
-model, there are no provisions to allow alternate names or aliases.
-However, this is not to say that DNS aliases, different names
-for each interface, etc., are constrained in any way.
-.Pp
-It is also important to note that Autokey verifies authenticity
-using the host name, network address and public keys,
-all of which are bound together by the protocol specifically
-to deflect masquerade attacks.
-For this reason Autokey
-includes the source and destinatino IP addresses in message digest
-computations and so the same addresses must be available
-at both the server and client.
-For this reason operation
-with network address translation schemes is not possible.
-This reflects the intended robust security model where government
-and corporate NTP servers are operated outside firewall perimeters.
-.Ss Operation
-A specific combination of authentication scheme (none,
-symmetric key, public key) and identity scheme is called
-a cryptotype, although not all combinations are compatible.
-There may be management configurations where the clients,
-servers and peers may not all support the same cryptotypes.
-A secure NTPv4 subnet can be configured in many ways while
-keeping in mind the principles explained above and
-in this section.
-Note however that some cryptotype
-combinations may successfully interoperate with each other,
-but may not represent good security practice.
-.Pp
-The cryptotype of an association is determined at the time
-of mobilization, either at configuration time or some time
-later when a message of appropriate cryptotype arrives.
-When mobilized by a
-.Ic server
-or
-.Ic peer
-configuration command and no
-.Ic key
-or
-.Ic autokey
-subcommands are present, the association is not
-authenticated; if the
-.Ic key
-subcommand is present, the association is authenticated
-using the symmetric key ID specified; if the
-.Ic autokey
-subcommand is present, the association is authenticated
-using Autokey.
-.Pp
-When multiple identity schemes are supported in the Autokey
-protocol, the first message exchange determines which one is used.
-The client request message contains bits corresponding
-to which schemes it has available.
-The server response message
-contains bits corresponding to which schemes it has available.
-Both server and client match the received bits with their own
-and select a common scheme.
-.Pp
-Following the principle that time is a public value,
-a server responds to any client packet that matches
-its cryptotype capabilities.
-Thus, a server receiving
-an unauthenticated packet will respond with an unauthenticated
-packet, while the same server receiving a packet of a cryptotype
-it supports will respond with packets of that cryptotype.
-However, unconfigured broadcast or manycast client
-associations or symmetric passive associations will not be
-mobilized unless the server supports a cryptotype compatible
-with the first packet received.
-By default, unauthenticated associations will not be mobilized
-unless overridden in a decidedly dangerous way.
-.Pp
-Some examples may help to reduce confusion.
-Client Alice has no specific cryptotype selected.
-Server Bob has both a symmetric key file and minimal Autokey files.
-Alice's unauthenticated messages arrive at Bob, who replies with
-unauthenticated messages.
-Cathy has a copy of Bob's symmetric
-key file and has selected key ID 4 in messages to Bob.
-Bob verifies the message with his key ID 4.
-If it's the
-same key and the message is verified, Bob sends Cathy a reply
-authenticated with that key.
-If verification fails,
-Bob sends Cathy a thing called a crypto-NAK, which tells her
-something broke.
-She can see the evidence using the ntpq program.
-.Pp
-Denise has rolled her own host key and certificate.
-She also uses one of the identity schemes as Bob.
-She sends the first Autokey message to Bob and they
-both dance the protocol authentication and identity steps.
-If all comes out okay, Denise and Bob continue as described above.
-.Pp
-It should be clear from the above that Bob can support
-all the girls at the same time, as long as he has compatible
-authentication and identity credentials.
-Now, Bob can act just like the girls in his own choice of servers;
-he can run multiple configured associations with multiple different
-servers (or the same server, although that might not be useful).
-But, wise security policy might preclude some cryptotype
-combinations; for instance, running an identity scheme
-with one server and no authentication with another might not be wise.
-.Ss Key Management
-The cryptographic values used by the Autokey protocol are
-incorporated as a set of files generated by the
-.Xr ntp-keygen 1ntpkeygenmdoc
-utility program, including symmetric key, host key and
-public certificate files, as well as sign key, identity parameters
-and leapseconds files.
-Alternatively, host and sign keys and
-certificate files can be generated by the OpenSSL utilities
-and certificates can be imported from public certificate
-authorities.
-Note that symmetric keys are necessary for the
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-utility programs.
-The remaining files are necessary only for the
-Autokey protocol.
-.Pp
-Certificates imported from OpenSSL or public certificate
-authorities have certian limitations.
-The certificate should be in ASN.1 syntax, X.509 Version 3
-format and encoded in PEM, which is the same format
-used by OpenSSL.
-The overall length of the certificate encoded
-in ASN.1 must not exceed 1024 bytes.
-The subject distinguished
-name field (CN) is the fully qualified name of the host
-on which it is used; the remaining subject fields are ignored.
-The certificate extension fields must not contain either
-a subject key identifier or a issuer key identifier field;
-however, an extended key usage field for a trusted host must
-contain the value
-.Cm trustRoot ; .
-Other extension fields are ignored.
-.Ss Authentication Commands
-.Bl -tag -width indent
-.It Ic autokey Op Ar logsec
-Specifies the interval between regenerations of the session key
-list used with the Autokey protocol.
-Note that the size of the key
-list for each association depends on this interval and the current
-poll interval.
-The default value is 12 (4096 s or about 1.1 hours).
-For poll intervals above the specified interval, a session key list
-with a single entry will be regenerated for every message
-sent.
-.It Ic controlkey Ar key
-Specifies the key identifier to use with the
-.Xr ntpq @NTPQ_MS@
-utility, which uses the standard
-protocol defined in RFC-1305.
-The
-.Ar key
-argument is
-the key identifier for a trusted key, where the value can be in the
-range 1 to 65,534, inclusive.
-.It Xo Ic crypto
-.Op Cm cert Ar file
-.Op Cm leap Ar file
-.Op Cm randfile Ar file
-.Op Cm host Ar file
-.Op Cm sign Ar file
-.Op Cm gq Ar file
-.Op Cm gqpar Ar file
-.Op Cm iffpar Ar file
-.Op Cm mvpar Ar file
-.Op Cm pw Ar password
-.Xc
-This command requires the OpenSSL library.
-It activates public key
-cryptography, selects the message digest and signature
-encryption scheme and loads the required private and public
-values described above.
-If one or more files are left unspecified,
-the default names are used as described above.
-Unless the complete path and name of the file are specified, the
-location of a file is relative to the keys directory specified
-in the
-.Ic keysdir
-command or default
-.Pa /usr/local/etc .
-Following are the subcommands:
-.Bl -tag -width indent
-.It Cm cert Ar file
-Specifies the location of the required host public certificate file.
-This overrides the link
-.Pa ntpkey_cert_ Ns Ar hostname
-in the keys directory.
-.It Cm gqpar Ar file
-Specifies the location of the optional GQ parameters file.
-This
-overrides the link
-.Pa ntpkey_gq_ Ns Ar hostname
-in the keys directory.
-.It Cm host Ar file
-Specifies the location of the required host key file.
-This overrides
-the link
-.Pa ntpkey_key_ Ns Ar hostname
-in the keys directory.
-.It Cm iffpar Ar file
-Specifies the location of the optional IFF parameters file.This
-overrides the link
-.Pa ntpkey_iff_ Ns Ar hostname
-in the keys directory.
-.It Cm leap Ar file
-Specifies the location of the optional leapsecond file.
-This overrides the link
-.Pa ntpkey_leap
-in the keys directory.
-.It Cm mvpar Ar file
-Specifies the location of the optional MV parameters file.
-This
-overrides the link
-.Pa ntpkey_mv_ Ns Ar hostname
-in the keys directory.
-.It Cm pw Ar password
-Specifies the password to decrypt files containing private keys and
-identity parameters.
-This is required only if these files have been
-encrypted.
-.It Cm randfile Ar file
-Specifies the location of the random seed file used by the OpenSSL
-library.
-The defaults are described in the main text above.
-.It Cm sign Ar file
-Specifies the location of the optional sign key file.
-This overrides
-the link
-.Pa ntpkey_sign_ Ns Ar hostname
-in the keys directory.
-If this file is
-not found, the host key is also the sign key.
-.El
-.It Ic keys Ar keyfile
-Specifies the complete path and location of the MD5 key file
-containing the keys and key identifiers used by
-.Xr ntpd @NTPD_MS@ ,
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-when operating with symmetric key cryptography.
-This is the same operation as the
-.Fl k
-command line option.
-.It Ic keysdir Ar path
-This command specifies the default directory path for
-cryptographic keys, parameters and certificates.
-The default is
-.Pa /usr/local/etc/ .
-.It Ic requestkey Ar key
-Specifies the key identifier to use with the
-.Xr ntpdc @NTPDC_MS@
-utility program, which uses a
-proprietary protocol specific to this implementation of
-.Xr ntpd @NTPD_MS@ .
-The
-.Ar key
-argument is a key identifier
-for the trusted key, where the value can be in the range 1 to
-65,534, inclusive.
-.It Ic revoke Ar logsec
-Specifies the interval between re-randomization of certain
-cryptographic values used by the Autokey scheme, as a power of 2 in
-seconds.
-These values need to be updated frequently in order to
-deflect brute-force attacks on the algorithms of the scheme;
-however, updating some values is a relatively expensive operation.
-The default interval is 16 (65,536 s or about 18 hours).
-For poll
-intervals above the specified interval, the values will be updated
-for every message sent.
-.It Ic trustedkey Ar key ...
-Specifies the key identifiers which are trusted for the
-purposes of authenticating peers with symmetric key cryptography,
-as well as keys used by the
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-programs.
-The authentication procedures require that both the local
-and remote servers share the same key and key identifier for this
-purpose, although different keys can be used with different
-servers.
-The
-.Ar key
-arguments are 32-bit unsigned
-integers with values from 1 to 65,534.
-.El
-.Ss Error Codes
-The following error codes are reported via the NTP control
-and monitoring protocol trap mechanism.
-.Bl -tag -width indent
-.It 101
-.Pq bad field format or length
-The packet has invalid version, length or format.
-.It 102
-.Pq bad timestamp
-The packet timestamp is the same or older than the most recent received.
-This could be due to a replay or a server clock time step.
-.It 103
-.Pq bad filestamp
-The packet filestamp is the same or older than the most recent received.
-This could be due to a replay or a key file generation error.
-.It 104
-.Pq bad or missing public key
-The public key is missing, has incorrect format or is an unsupported type.
-.It 105
-.Pq unsupported digest type
-The server requires an unsupported digest/signature scheme.
-.It 106
-.Pq mismatched digest types
-Not used.
-.It 107
-.Pq bad signature length
-The signature length does not match the current public key.
-.It 108
-.Pq signature not verified
-The message fails the signature check.
-It could be bogus or signed by a
-different private key.
-.It 109
-.Pq certificate not verified
-The certificate is invalid or signed with the wrong key.
-.It 110
-.Pq certificate not verified
-The certificate is not yet valid or has expired or the signature could not
-be verified.
-.It 111
-.Pq bad or missing cookie
-The cookie is missing, corrupted or bogus.
-.It 112
-.Pq bad or missing leapseconds table
-The leapseconds table is missing, corrupted or bogus.
-.It 113
-.Pq bad or missing certificate
-The certificate is missing, corrupted or bogus.
-.It 114
-.Pq bad or missing identity
-The identity key is missing, corrupt or bogus.
-.El
-.Sh Monitoring Support
-.Xr ntpd @NTPD_MS@
-includes a comprehensive monitoring facility suitable
-for continuous, long term recording of server and client
-timekeeping performance.
-See the
-.Ic statistics
-command below
-for a listing and example of each type of statistics currently
-supported.
-Statistic files are managed using file generation sets
-and scripts in the
-.Pa ./scripts
-directory of this distribution.
-Using
-these facilities and
-.Ux
-.Xr cron 8
-jobs, the data can be
-automatically summarized and archived for retrospective analysis.
-.Ss Monitoring Commands
-.Bl -tag -width indent
-.It Ic statistics Ar name ...
-Enables writing of statistics records.
-Currently, four kinds of
-.Ar name
-statistics are supported.
-.Bl -tag -width indent
-.It Cm clockstats
-Enables recording of clock driver statistics information.
-Each update
-received from a clock driver appends a line of the following form to
-the file generation set named
-.Cm clockstats :
-.Bd -literal
-49213 525.624 127.127.4.1 93 226 00:08:29.606 D
-.Ed
-.Pp
-The first two fields show the date (Modified Julian Day) and time
-(seconds and fraction past UTC midnight).
-The next field shows the
-clock address in dotted-quad notation.
-The final field shows the last
-timecode received from the clock in decoded ASCII format, where
-meaningful.
-In some clock drivers a good deal of additional information
-can be gathered and displayed as well.
-See information specific to each
-clock for further details.
-.It Cm cryptostats
-This option requires the OpenSSL cryptographic software library.
-It
-enables recording of cryptographic public key protocol information.
-Each message received by the protocol module appends a line of the
-following form to the file generation set named
-.Cm cryptostats :
-.Bd -literal
-49213 525.624 127.127.4.1 message
-.Ed
-.Pp
-The first two fields show the date (Modified Julian Day) and time
-(seconds and fraction past UTC midnight).
-The next field shows the peer
-address in dotted-quad notation, The final message field includes the
-message type and certain ancillary information.
-See the
-.Sx Authentication Options
-section for further information.
-.It Cm loopstats
-Enables recording of loop filter statistics information.
-Each
-update of the local clock outputs a line of the following form to
-the file generation set named
-.Cm loopstats :
-.Bd -literal
-50935 75440.031 0.000006019 13.778190 0.000351733 0.0133806
-.Ed
-.Pp
-The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight).
-The next five fields
-show time offset (seconds), frequency offset (parts per million -
-PPM), RMS jitter (seconds), Allan deviation (PPM) and clock
-discipline time constant.
-.It Cm peerstats
-Enables recording of peer statistics information.
-This includes
-statistics records of all peers of a NTP server and of special
-signals, where present and configured.
-Each valid update appends a
-line of the following form to the current element of a file
-generation set named
-.Cm peerstats :
-.Bd -literal
-48773 10847.650 127.127.4.1 9714 -0.001605376 0.000000000 0.001424877 0.000958674
-.Ed
-.Pp
-The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight).
-The next two fields
-show the peer address in dotted-quad notation and status,
-respectively.
-The status field is encoded in hex in the format
-described in Appendix A of the NTP specification RFC 1305.
-The final four fields show the offset,
-delay, dispersion and RMS jitter, all in seconds.
-.It Cm rawstats
-Enables recording of raw-timestamp statistics information.
-This
-includes statistics records of all peers of a NTP server and of
-special signals, where present and configured.
-Each NTP message
-received from a peer or clock driver appends a line of the
-following form to the file generation set named
-.Cm rawstats :
-.Bd -literal
-50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 3102453281.58622800031 02453332.540806000 3102453332.541458000
-.Ed
-.Pp
-The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight).
-The next two fields
-show the remote peer or clock address followed by the local address
-in dotted-quad notation.
-The final four fields show the originate,
-receive, transmit and final NTP timestamps in order.
-The timestamp
-values are as received and before processing by the various data
-smoothing and mitigation algorithms.
-.It Cm sysstats
-Enables recording of ntpd statistics counters on a periodic basis.
-Each
-hour a line of the following form is appended to the file generation
-set named
-.Cm sysstats :
-.Bd -literal
-50928 2132.543 36000 81965 0 9546 56 71793 512 540 10 147
-.Ed
-.Pp
-The first two fields show the date (Modified Julian Day) and time
-(seconds and fraction past UTC midnight).
-The remaining ten fields show
-the statistics counter values accumulated since the last generated
-line.
-.Bl -tag -width indent
-.It Time since restart Cm 36000
-Time in hours since the system was last rebooted.
-.It Packets received Cm 81965
-Total number of packets received.
-.It Packets processed Cm 0
-Number of packets received in response to previous packets sent
-.It Current version Cm 9546
-Number of packets matching the current NTP version.
-.It Previous version Cm 56
-Number of packets matching the previous NTP version.
-.It Bad version Cm 71793
-Number of packets matching neither NTP version.
-.It Access denied Cm 512
-Number of packets denied access for any reason.
-.It Bad length or format Cm 540
-Number of packets with invalid length, format or port number.
-.It Bad authentication Cm 10
-Number of packets not verified as authentic.
-.It Rate exceeded Cm 147
-Number of packets discarded due to rate limitation.
-.El
-.It Cm statsdir Ar directory_path
-Indicates the full path of a directory where statistics files
-should be created (see below).
-This keyword allows
-the (otherwise constant)
-.Cm filegen
-filename prefix to be modified for file generation sets, which
-is useful for handling statistics logs.
-.It Cm filegen Ar name Xo
-.Op Cm file Ar filename
-.Op Cm type Ar typename
-.Op Cm link | nolink
-.Op Cm enable | disable
-.Xc
-Configures setting of generation file set name.
-Generation
-file sets provide a means for handling files that are
-continuously growing during the lifetime of a server.
-Server statistics are a typical example for such files.
-Generation file sets provide access to a set of files used
-to store the actual data.
-At any time at most one element
-of the set is being written to.
-The type given specifies
-when and how data will be directed to a new element of the set.
-This way, information stored in elements of a file set
-that are currently unused are available for administrational
-operations without the risk of disturbing the operation of ntpd.
-(Most important: they can be removed to free space for new data
-produced.)
-.Pp
-Note that this command can be sent from the
-.Xr ntpdc @NTPDC_MS@
-program running at a remote location.
-.Bl -tag -width indent
-.It Cm name
-This is the type of the statistics records, as shown in the
-.Cm statistics
-command.
-.It Cm file Ar filename
-This is the file name for the statistics records.
-Filenames of set
-members are built from three concatenated elements
-.Ar Cm prefix ,
-.Ar Cm filename
-and
-.Ar Cm suffix :
-.Bl -tag -width indent
-.It Cm prefix
-This is a constant filename path.
-It is not subject to
-modifications via the
-.Ar filegen
-option.
-It is defined by the
-server, usually specified as a compile-time constant.
-It may,
-however, be configurable for individual file generation sets
-via other commands.
-For example, the prefix used with
-.Ar loopstats
-and
-.Ar peerstats
-generation can be configured using the
-.Ar statsdir
-option explained above.
-.It Cm filename
-This string is directly concatenated to the prefix mentioned
-above (no intervening
-.Ql / ) .
-This can be modified using
-the file argument to the
-.Ar filegen
-statement.
-No
-.Pa ..
-elements are
-allowed in this component to prevent filenames referring to
-parts outside the filesystem hierarchy denoted by
-.Ar prefix .
-.It Cm suffix
-This part is reflects individual elements of a file set.
-It is
-generated according to the type of a file set.
-.El
-.It Cm type Ar typename
-A file generation set is characterized by its type.
-The following
-types are supported:
-.Bl -tag -width indent
-.It Cm none
-The file set is actually a single plain file.
-.It Cm pid
-One element of file set is used per incarnation of a ntpd
-server.
-This type does not perform any changes to file set
-members during runtime, however it provides an easy way of
-separating files belonging to different
-.Xr ntpd @NTPD_MS@
-server incarnations.
-The set member filename is built by appending a
-.Ql \&.
-to concatenated
-.Ar prefix
-and
-.Ar filename
-strings, and
-appending the decimal representation of the process ID of the
-.Xr ntpd @NTPD_MS@
-server process.
-.It Cm day
-One file generation set element is created per day.
-A day is
-defined as the period between 00:00 and 24:00 UTC.
-The file set
-member suffix consists of a
-.Ql \&.
-and a day specification in
-the form
-.Cm YYYYMMdd .
-.Cm YYYY
-is a 4-digit year number (e.g., 1992).
-.Cm MM
-is a two digit month number.
-.Cm dd
-is a two digit day number.
-Thus, all information written at 10 December 1992 would end up
-in a file named
-.Ar prefix
-.Ar filename Ns .19921210 .
-.It Cm week
-Any file set member contains data related to a certain week of
-a year.
-The term week is defined by computing day-of-year
-modulo 7.
-Elements of such a file generation set are
-distinguished by appending the following suffix to the file set
-filename base: A dot, a 4-digit year number, the letter
-.Cm W ,
-and a 2-digit week number.
-For example, information from January,
-10th 1992 would end up in a file with suffix
-.No . Ns Ar 1992W1 .
-.It Cm month
-One generation file set element is generated per month.
-The
-file name suffix consists of a dot, a 4-digit year number, and
-a 2-digit month.
-.It Cm year
-One generation file element is generated per year.
-The filename
-suffix consists of a dot and a 4 digit year number.
-.It Cm age
-This type of file generation sets changes to a new element of
-the file set every 24 hours of server operation.
-The filename
-suffix consists of a dot, the letter
-.Cm a ,
-and an 8-digit number.
-This number is taken to be the number of seconds the server is
-running at the start of the corresponding 24-hour period.
-Information is only written to a file generation by specifying
-.Cm enable ;
-output is prevented by specifying
-.Cm disable .
-.El
-.It Cm link | nolink
-It is convenient to be able to access the current element of a file
-generation set by a fixed name.
-This feature is enabled by
-specifying
-.Cm link
-and disabled using
-.Cm nolink .
-If link is specified, a
-hard link from the current file set element to a file without
-suffix is created.
-When there is already a file with this name and
-the number of links of this file is one, it is renamed appending a
-dot, the letter
-.Cm C ,
-and the pid of the ntpd server process.
-When the
-number of links is greater than one, the file is unlinked.
-This
-allows the current file to be accessed by a constant name.
-.It Cm enable \&| Cm disable
-Enables or disables the recording function.
-.El
-.El
-.El
-.Sh Access Control Support
-The
-.Xr ntpd @NTPD_MS@
-daemon implements a general purpose address/mask based restriction
-list.
-The list contains address/match entries sorted first
-by increasing address values and and then by increasing mask values.
-A match occurs when the bitwise AND of the mask and the packet
-source address is equal to the bitwise AND of the mask and
-address in the list.
-The list is searched in order with the
-last match found defining the restriction flags associated
-with the entry.
-Additional information and examples can be found in the
-.Qq Notes on Configuring NTP and Setting up a NTP Subnet
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.Pp
-The restriction facility was implemented in conformance
-with the access policies for the original NSFnet backbone
-time servers.
-Later the facility was expanded to deflect
-cryptographic and clogging attacks.
-While this facility may
-be useful for keeping unwanted or broken or malicious clients
-from congesting innocent servers, it should not be considered
-an alternative to the NTP authentication facilities.
-Source address based restrictions are easily circumvented
-by a determined cracker.
-.Pp
-Clients can be denied service because they are explicitly
-included in the restrict list created by the restrict command
-or implicitly as the result of cryptographic or rate limit
-violations.
-Cryptographic violations include certificate
-or identity verification failure; rate limit violations generally
-result from defective NTP implementations that send packets
-at abusive rates.
-Some violations cause denied service
-only for the offending packet, others cause denied service
-for a timed period and others cause the denied service for
-an indefinate period.
-When a client or network is denied access
-for an indefinate period, the only way at present to remove
-the restrictions is by restarting the server.
-.Ss The Kiss-of-Death Packet
-Ordinarily, packets denied service are simply dropped with no
-further action except incrementing statistics counters.
-Sometimes a
-more proactive response is needed, such as a server message that
-explicitly requests the client to stop sending and leave a message
-for the system operator.
-A special packet format has been created
-for this purpose called the "kiss-of-death" (KoD) packet.
-KoD packets have the leap bits set unsynchronized and stratum set
-to zero and the reference identifier field set to a four-byte
-ASCII code.
-If the
-.Cm noserve
-or
-.Cm notrust
-flag of the matching restrict list entry is set,
-the code is "DENY"; if the
-.Cm limited
-flag is set and the rate limit
-is exceeded, the code is "RATE".
-Finally, if a cryptographic violation occurs, the code is "CRYP".
-.Pp
-A client receiving a KoD performs a set of sanity checks to
-minimize security exposure, then updates the stratum and
-reference identifier peer variables, sets the access
-denied (TEST4) bit in the peer flash variable and sends
-a message to the log.
-As long as the TEST4 bit is set,
-the client will send no further packets to the server.
-The only way at present to recover from this condition is
-to restart the protocol at both the client and server.
-This
-happens automatically at the client when the association times out.
-It will happen at the server only if the server operator cooperates.
-.Ss Access Control Commands
-.Bl -tag -width indent
-.It Xo Ic discard
-.Op Cm average Ar avg
-.Op Cm minimum Ar min
-.Op Cm monitor Ar prob
-.Xc
-Set the parameters of the
-.Cm limited
-facility which protects the server from
-client abuse.
-The
-.Cm average
-subcommand specifies the minimum average packet
-spacing, while the
-.Cm minimum
-subcommand specifies the minimum packet spacing.
-Packets that violate these minima are discarded
-and a kiss-o'-death packet returned if enabled.
-The default
-minimum average and minimum are 5 and 2, respectively.
-The monitor subcommand specifies the probability of discard
-for packets that overflow the rate-control window.
-.It Xo Ic restrict address
-.Op Cm mask Ar mask
-.Op Ar flag ...
-.Xc
-The
-.Ar address
-argument expressed in
-dotted-quad form is the address of a host or network.
-Alternatively, the
-.Ar address
-argument can be a valid host DNS name.
-The
-.Ar mask
-argument expressed in dotted-quad form defaults to
-.Cm 255.255.255.255 ,
-meaning that the
-.Ar address
-is treated as the address of an individual host.
-A default entry (address
-.Cm 0.0.0.0 ,
-mask
-.Cm 0.0.0.0 )
-is always included and is always the first entry in the list.
-Note that text string
-.Cm default ,
-with no mask option, may
-be used to indicate the default entry.
-In the current implementation,
-.Cm flag
-always
-restricts access, i.e., an entry with no flags indicates that free
-access to the server is to be given.
-The flags are not orthogonal,
-in that more restrictive flags will often make less restrictive
-ones redundant.
-The flags can generally be classed into two
-categories, those which restrict time service and those which
-restrict informational queries and attempts to do run-time
-reconfiguration of the server.
-One or more of the following flags
-may be specified:
-.Bl -tag -width indent
-.It Cm ignore
-Deny packets of all kinds, including
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-queries.
-.It Cm kod
-If this flag is set when an access violation occurs, a kiss-o'-death
-(KoD) packet is sent.
-KoD packets are rate limited to no more than one
-per second.
-If another KoD packet occurs within one second after the
-last one, the packet is dropped.
-.It Cm limited
-Deny service if the packet spacing violates the lower limits specified
-in the discard command.
-A history of clients is kept using the
-monitoring capability of
-.Xr ntpd @NTPD_MS@ .
-Thus, monitoring is always active as
-long as there is a restriction entry with the
-.Cm limited
-flag.
-.It Cm lowpriotrap
-Declare traps set by matching hosts to be low priority.
-The
-number of traps a server can maintain is limited (the current limit
-is 3).
-Traps are usually assigned on a first come, first served
-basis, with later trap requestors being denied service.
-This flag
-modifies the assignment algorithm by allowing low priority traps to
-be overridden by later requests for normal priority traps.
-.It Cm nomodify
-Deny
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-queries which attempt to modify the state of the
-server (i.e., run time reconfiguration).
-Queries which return
-information are permitted.
-.It Cm noquery
-Deny
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-queries.
-Time service is not affected.
-.It Cm nopeer
-Deny packets which would result in mobilizing a new association.
-This
-includes broadcast and symmetric active packets when a configured
-association does not exist.
-.It Cm noserve
-Deny all packets except
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-queries.
-.It Cm notrap
-Decline to provide mode 6 control message trap service to matching
-hosts.
-The trap service is a subsystem of the ntpdq control message
-protocol which is intended for use by remote event logging programs.
-.It Cm notrust
-Deny service unless the packet is cryptographically authenticated.
-.It Cm ntpport
-This is actually a match algorithm modifier, rather than a
-restriction flag.
-Its presence causes the restriction entry to be
-matched only if the source port in the packet is the standard NTP
-UDP port (123).
-Both
-.Cm ntpport
-and
-.Cm non-ntpport
-may
-be specified.
-The
-.Cm ntpport
-is considered more specific and
-is sorted later in the list.
-.It Cm version
-Deny packets that do not match the current NTP version.
-.El
-.Pp
-Default restriction list entries with the flags ignore, interface,
-ntpport, for each of the local host's interface addresses are
-inserted into the table at startup to prevent the server
-from attempting to synchronize to its own time.
-A default entry is also always present, though if it is
-otherwise unconfigured; no flags are associated
-with the default entry (i.e., everything besides your own
-NTP server is unrestricted).
-.El
-.Sh Automatic NTP Configuration Options
-.Ss Manycasting
-Manycasting is a automatic discovery and configuration paradigm
-new to NTPv4.
-It is intended as a means for a multicast client
-to troll the nearby network neighborhood to find cooperating
-manycast servers, validate them using cryptographic means
-and evaluate their time values with respect to other servers
-that might be lurking in the vicinity.
-The intended result is that each manycast client mobilizes
-client associations with some number of the "best"
-of the nearby manycast servers, yet automatically reconfigures
-to sustain this number of servers should one or another fail.
-.Pp
-Note that the manycasting paradigm does not coincide
-with the anycast paradigm described in RFC-1546,
-which is designed to find a single server from a clique
-of servers providing the same service.
-The manycast paradigm is designed to find a plurality
-of redundant servers satisfying defined optimality criteria.
-.Pp
-Manycasting can be used with either symmetric key
-or public key cryptography.
-The public key infrastructure (PKI)
-offers the best protection against compromised keys
-and is generally considered stronger, at least with relatively
-large key sizes.
-It is implemented using the Autokey protocol and
-the OpenSSL cryptographic library available from
-.Li http://www.openssl.org/ .
-The library can also be used with other NTPv4 modes
-as well and is highly recommended, especially for broadcast modes.
-.Pp
-A persistent manycast client association is configured
-using the manycastclient command, which is similar to the
-server command but with a multicast (IPv4 class
-.Cm D
-or IPv6 prefix
-.Cm FF )
-group address.
-The IANA has designated IPv4 address 224.1.1.1
-and IPv6 address FF05::101 (site local) for NTP.
-When more servers are needed, it broadcasts manycast
-client messages to this address at the minimum feasible rate
-and minimum feasible time-to-live (TTL) hops, depending
-on how many servers have already been found.
-There can be as many manycast client associations
-as different group address, each one serving as a template
-for a future ephemeral unicast client/server association.
-.Pp
-Manycast servers configured with the
-.Ic manycastserver
-command listen on the specified group address for manycast
-client messages.
-Note the distinction between manycast client,
-which actively broadcasts messages, and manycast server,
-which passively responds to them.
-If a manycast server is
-in scope of the current TTL and is itself synchronized
-to a valid source and operating at a stratum level equal
-to or lower than the manycast client, it replies to the
-manycast client message with an ordinary unicast server message.
-.Pp
-The manycast client receiving this message mobilizes
-an ephemeral client/server association according to the
-matching manycast client template, but only if cryptographically
-authenticated and the server stratum is less than or equal
-to the client stratum.
-Authentication is explicitly required
-and either symmetric key or public key (Autokey) can be used.
-Then, the client polls the server at its unicast address
-in burst mode in order to reliably set the host clock
-and validate the source.
-This normally results
-in a volley of eight client/server at 2-s intervals
-during which both the synchronization and cryptographic
-protocols run concurrently.
-Following the volley,
-the client runs the NTP intersection and clustering
-algorithms, which act to discard all but the "best"
-associations according to stratum and synchronization
-distance.
-The surviving associations then continue
-in ordinary client/server mode.
-.Pp
-The manycast client polling strategy is designed to reduce
-as much as possible the volume of manycast client messages
-and the effects of implosion due to near-simultaneous
-arrival of manycast server messages.
-The strategy is determined by the
-.Ic manycastclient ,
-.Ic tos
-and
-.Ic ttl
-configuration commands.
-The manycast poll interval is
-normally eight times the system poll interval,
-which starts out at the
-.Cm minpoll
-value specified in the
-.Ic manycastclient ,
-command and, under normal circumstances, increments to the
-.Cm maxpolll
-value specified in this command.
-Initially, the TTL is
-set at the minimum hops specified by the ttl command.
-At each retransmission the TTL is increased until reaching
-the maximum hops specified by this command or a sufficient
-number client associations have been found.
-Further retransmissions use the same TTL.
-.Pp
-The quality and reliability of the suite of associations
-discovered by the manycast client is determined by the NTP
-mitigation algorithms and the
-.Cm minclock
-and
-.Cm minsane
-values specified in the
-.Ic tos
-configuration command.
-At least
-.Cm minsane
-candidate servers must be available and the mitigation
-algorithms produce at least
-.Cm minclock
-survivors in order to synchronize the clock.
-Byzantine agreement principles require at least four
-candidates in order to correctly discard a single falseticker.
-For legacy purposes,
-.Cm minsane
-defaults to 1 and
-.Cm minclock
-defaults to 3.
-For manycast service
-.Cm minsane
-should be explicitly set to 4, assuming at least that
-number of servers are available.
-.Pp
-If at least
-.Cm minclock
-servers are found, the manycast poll interval is immediately
-set to eight times
-.Cm maxpoll .
-If less than
-.Cm minclock
-servers are found when the TTL has reached the maximum hops,
-the manycast poll interval is doubled.
-For each transmission
-after that, the poll interval is doubled again until
-reaching the maximum of eight times
-.Cm maxpoll .
-Further transmissions use the same poll interval and
-TTL values.
-Note that while all this is going on,
-each client/server association found is operating normally
-it the system poll interval.
-.Pp
-Administratively scoped multicast boundaries are normally
-specified by the network router configuration and,
-in the case of IPv6, the link/site scope prefix.
-By default, the increment for TTL hops is 32 starting
-from 31; however, the
-.Ic ttl
-configuration command can be
-used to modify the values to match the scope rules.
-.Pp
-It is often useful to narrow the range of acceptable
-servers which can be found by manycast client associations.
-Because manycast servers respond only when the client
-stratum is equal to or greater than the server stratum,
-primary (stratum 1) servers fill find only primary servers
-in TTL range, which is probably the most common objective.
-However, unless configured otherwise, all manycast clients
-in TTL range will eventually find all primary servers
-in TTL range, which is probably not the most common
-objective in large networks.
-The
-.Ic tos
-command can be used to modify this behavior.
-Servers with stratum below
-.Cm floor
-or above
-.Cm ceiling
-specified in the
-.Ic tos
-command are strongly discouraged during the selection
-process; however, these servers may be temporally
-accepted if the number of servers within TTL range is
-less than
-.Cm minclock .
-.Pp
-The above actions occur for each manycast client message,
-which repeats at the designated poll interval.
-However, once the ephemeral client association is mobilized,
-subsequent manycast server replies are discarded,
-since that would result in a duplicate association.
-If during a poll interval the number of client associations
-falls below
-.Cm minclock ,
-all manycast client prototype associations are reset
-to the initial poll interval and TTL hops and operation
-resumes from the beginning.
-It is important to avoid
-frequent manycast client messages, since each one requires
-all manycast servers in TTL range to respond.
-The result could well be an implosion, either minor or major,
-depending on the number of servers in range.
-The recommended value for
-.Cm maxpoll
-is 12 (4,096 s).
-.Pp
-It is possible and frequently useful to configure a host
-as both manycast client and manycast server.
-A number of hosts configured this way and sharing a common
-group address will automatically organize themselves
-in an optimum configuration based on stratum and
-synchronization distance.
-For example, consider an NTP
-subnet of two primary servers and a hundred or more
-dependent clients.
-With two exceptions, all servers
-and clients have identical configuration files including both
-.Ic multicastclient
-and
-.Ic multicastserver
-commands using, for instance, multicast group address
-239.1.1.1.
-The only exception is that each primary server
-configuration file must include commands for the primary
-reference source such as a GPS receiver.
-.Pp
-The remaining configuration files for all secondary
-servers and clients have the same contents, except for the
-.Ic tos
-command, which is specific for each stratum level.
-For stratum 1 and stratum 2 servers, that command is
-not necessary.
-For stratum 3 and above servers the
-.Cm floor
-value is set to the intended stratum number.
-Thus, all stratum 3 configuration files are identical,
-all stratum 4 files are identical and so forth.
-.Pp
-Once operations have stabilized in this scenario,
-the primary servers will find the primary reference source
-and each other, since they both operate at the same
-stratum (1), but not with any secondary server or client,
-since these operate at a higher stratum.
-The secondary
-servers will find the servers at the same stratum level.
-If one of the primary servers loses its GPS receiver,
-it will continue to operate as a client and other clients
-will time out the corresponding association and
-re-associate accordingly.
-.Pp
-Some administrators prefer to avoid running
-.Xr ntpd @NTPD_MS@
-continuously and run either
-.Xr ntpdate 8
-or
-.Xr ntpd @NTPD_MS@
-.Fl q
-as a cron job.
-In either case the servers must be
-configured in advance and the program fails if none are
-available when the cron job runs.
-A really slick
-application of manycast is with
-.Xr ntpd @NTPD_MS@
-.Fl q .
-The program wakes up, scans the local landscape looking
-for the usual suspects, selects the best from among
-the rascals, sets the clock and then departs.
-Servers do not have to be configured in advance and
-all clients throughout the network can have the same
-configuration file.
-.Ss Manycast Interactions with Autokey
-Each time a manycast client sends a client mode packet
-to a multicast group address, all manycast servers
-in scope generate a reply including the host name
-and status word.
-The manycast clients then run
-the Autokey protocol, which collects and verifies
-all certificates involved.
-Following the burst interval
-all but three survivors are cast off,
-but the certificates remain in the local cache.
-It often happens that several complete signing trails
-from the client to the primary servers are collected in this way.
-.Pp
-About once an hour or less often if the poll interval
-exceeds this, the client regenerates the Autokey key list.
-This is in general transparent in client/server mode.
-However, about once per day the server private value
-used to generate cookies is refreshed along with all
-manycast client associations.
-In this case all
-cryptographic values including certificates is refreshed.
-If a new certificate has been generated since
-the last refresh epoch, it will automatically revoke
-all prior certificates that happen to be in the
-certificate cache.
-At the same time, the manycast
-scheme starts all over from the beginning and
-the expanding ring shrinks to the minimum and increments
-from there while collecting all servers in scope.
-.Ss Manycast Options
-.Bl -tag -width indent
-.It Xo Ic tos
-.Oo
-.Cm ceiling Ar ceiling |
-.Cm cohort { 0 | 1 } |
-.Cm floor Ar floor |
-.Cm minclock Ar minclock |
-.Cm minsane Ar minsane
-.Oc
-.Xc
-This command affects the clock selection and clustering
-algorithms.
-It can be used to select the quality and
-quantity of peers used to synchronize the system clock
-and is most useful in manycast mode.
-The variables operate
-as follows:
-.Bl -tag -width indent
-.It Cm ceiling Ar ceiling
-Peers with strata above
-.Cm ceiling
-will be discarded if there are at least
-.Cm minclock
-peers remaining.
-This value defaults to 15, but can be changed
-to any number from 1 to 15.
-.It Cm cohort Bro 0 | 1 Brc
-This is a binary flag which enables (0) or disables (1)
-manycast server replies to manycast clients with the same
-stratum level.
-This is useful to reduce implosions where
-large numbers of clients with the same stratum level
-are present.
-The default is to enable these replies.
-.It Cm floor Ar floor
-Peers with strata below
-.Cm floor
-will be discarded if there are at least
-.Cm minclock
-peers remaining.
-This value defaults to 1, but can be changed
-to any number from 1 to 15.
-.It Cm minclock Ar minclock
-The clustering algorithm repeatedly casts out outlyer
-associations until no more than
-.Cm minclock
-associations remain.
-This value defaults to 3,
-but can be changed to any number from 1 to the number of
-configured sources.
-.It Cm minsane Ar minsane
-This is the minimum number of candidates available
-to the clock selection algorithm in order to produce
-one or more truechimers for the clustering algorithm.
-If fewer than this number are available, the clock is
-undisciplined and allowed to run free.
-The default is 1
-for legacy purposes.
-However, according to principles of
-Byzantine agreement,
-.Cm minsane
-should be at least 4 in order to detect and discard
-a single falseticker.
-.El
-.It Cm ttl Ar hop ...
-This command specifies a list of TTL values in increasing
-order, up to 8 values can be specified.
-In manycast mode these values are used in turn
-in an expanding-ring search.
-The default is eight
-multiples of 32 starting at 31.
-.El
-.Sh Reference Clock Support
-The NTP Version 4 daemon supports some three dozen different radio,
-satellite and modem reference clocks plus a special pseudo-clock
-used for backup or when no other clock source is available.
-Detailed descriptions of individual device drivers and options can
-be found in the
-.Qq Reference Clock Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-Additional information can be found in the pages linked
-there, including the
-.Qq Debugging Hints for Reference Clock Drivers
-and
-.Qq How To Write a Reference Clock Driver
-pages
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-In addition, support for a PPS
-signal is available as described in the
-.Qq Pulse-per-second (PPS) Signal Interfacing
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-Many
-drivers support special line discipline/streams modules which can
-significantly improve the accuracy using the driver.
-These are
-described in the
-.Qq Line Disciplines and Streams Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.Pp
-A reference clock will generally (though not always) be a radio
-timecode receiver which is synchronized to a source of standard
-time such as the services offered by the NRC in Canada and NIST and
-USNO in the US.
-The interface between the computer and the timecode
-receiver is device dependent, but is usually a serial port.
-A
-device driver specific to each reference clock must be selected and
-compiled in the distribution; however, most common radio, satellite
-and modem clocks are included by default.
-Note that an attempt to
-configure a reference clock when the driver has not been compiled
-or the hardware port has not been appropriately configured results
-in a scalding remark to the system log file, but is otherwise non
-hazardous.
-.Pp
-For the purposes of configuration,
-.Xr ntpd @NTPD_MS@
-treats
-reference clocks in a manner analogous to normal NTP peers as much
-as possible.
-Reference clocks are identified by a syntactically
-correct but invalid IP address, in order to distinguish them from
-normal NTP peers.
-Reference clock addresses are of the form
-.Sm off
-.Li 127.127. Ar t . Ar u ,
-.Sm on
-where
-.Ar t
-is an integer
-denoting the clock type and
-.Ar u
-indicates the unit
-number in the range 0-3.
-While it may seem overkill, it is in fact
-sometimes useful to configure multiple reference clocks of the same
-type, in which case the unit numbers must be unique.
-.Pp
-The
-.Ic server
-command is used to configure a reference
-clock, where the
-.Ar address
-argument in that command
-is the clock address.
-The
-.Cm key ,
-.Cm version
-and
-.Cm ttl
-options are not used for reference clock support.
-The
-.Cm mode
-option is added for reference clock support, as
-described below.
-The
-.Cm prefer
-option can be useful to
-persuade the server to cherish a reference clock with somewhat more
-enthusiasm than other reference clocks or peers.
-Further
-information on this option can be found in the
-.Qq Mitigation Rules and the prefer Keyword
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-page.
-The
-.Cm minpoll
-and
-.Cm maxpoll
-options have
-meaning only for selected clock drivers.
-See the individual clock
-driver document pages for additional information.
-.Pp
-The
-.Ic fudge
-command is used to provide additional
-information for individual clock drivers and normally follows
-immediately after the
-.Ic server
-command.
-The
-.Ar address
-argument specifies the clock address.
-The
-.Cm refid
-and
-.Cm stratum
-options can be used to
-override the defaults for the device.
-There are two optional
-device-dependent time offsets and four flags that can be included
-in the
-.Ic fudge
-command as well.
-.Pp
-The stratum number of a reference clock is by default zero.
-Since the
-.Xr ntpd @NTPD_MS@
-daemon adds one to the stratum of each
-peer, a primary server ordinarily displays an external stratum of
-one.
-In order to provide engineered backups, it is often useful to
-specify the reference clock stratum as greater than zero.
-The
-.Cm stratum
-option is used for this purpose.
-Also, in cases
-involving both a reference clock and a pulse-per-second (PPS)
-discipline signal, it is useful to specify the reference clock
-identifier as other than the default, depending on the driver.
-The
-.Cm refid
-option is used for this purpose.
-Except where noted,
-these options apply to all clock drivers.
-.Ss Reference Clock Commands
-.Bl -tag -width indent
-.It Xo Ic server
-.Sm off
-.Li 127.127. Ar t . Ar u
-.Sm on
-.Op Cm prefer
-.Op Cm mode Ar int
-.Op Cm minpoll Ar int
-.Op Cm maxpoll Ar int
-.Xc
-This command can be used to configure reference clocks in
-special ways.
-The options are interpreted as follows:
-.Bl -tag -width indent
-.It Cm prefer
-Marks the reference clock as preferred.
-All other things being
-equal, this host will be chosen for synchronization among a set of
-correctly operating hosts.
-See the
-.Qq Mitigation Rules and the prefer Keyword
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-for further information.
-.It Cm mode Ar int
-Specifies a mode number which is interpreted in a
-device-specific fashion.
-For instance, it selects a dialing
-protocol in the ACTS driver and a device subtype in the
-parse
-drivers.
-.It Cm minpoll Ar int
-.It Cm maxpoll Ar int
-These options specify the minimum and maximum polling interval
-for reference clock messages, as a power of 2 in seconds
-For
-most directly connected reference clocks, both
-.Cm minpoll
-and
-.Cm maxpoll
-default to 6 (64 s).
-For modem reference clocks,
-.Cm minpoll
-defaults to 10 (17.1 m) and
-.Cm maxpoll
-defaults to 14 (4.5 h).
-The allowable range is 4 (16 s) to 17 (36.4 h) inclusive.
-.El
-.It Xo Ic fudge
-.Sm off
-.Li 127.127. Ar t . Ar u
-.Sm on
-.Op Cm time1 Ar sec
-.Op Cm time2 Ar sec
-.Op Cm stratum Ar int
-.Op Cm refid Ar string
-.Op Cm mode Ar int
-.Op Cm flag1 Cm 0 \&| Cm 1
-.Op Cm flag2 Cm 0 \&| Cm 1
-.Op Cm flag3 Cm 0 \&| Cm 1
-.Op Cm flag4 Cm 0 \&| Cm 1
-.Xc
-This command can be used to configure reference clocks in
-special ways.
-It must immediately follow the
-.Ic server
-command which configures the driver.
-Note that the same capability
-is possible at run time using the
-.Xr ntpdc @NTPDC_MS@
-program.
-The options are interpreted as
-follows:
-.Bl -tag -width indent
-.It Cm time1 Ar sec
-Specifies a constant to be added to the time offset produced by
-the driver, a fixed-point decimal number in seconds.
-This is used
-as a calibration constant to adjust the nominal time offset of a
-particular clock to agree with an external standard, such as a
-precision PPS signal.
-It also provides a way to correct a
-systematic error or bias due to serial port or operating system
-latencies, different cable lengths or receiver internal delay.
-The
-specified offset is in addition to the propagation delay provided
-by other means, such as internal DIPswitches.
-Where a calibration
-for an individual system and driver is available, an approximate
-correction is noted in the driver documentation pages.
-Note: in order to facilitate calibration when more than one
-radio clock or PPS signal is supported, a special calibration
-feature is available.
-It takes the form of an argument to the
-.Ic enable
-command described in
-.Sx Miscellaneous Options
-page and operates as described in the
-.Qq Reference Clock Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.It Cm time2 Ar secs
-Specifies a fixed-point decimal number in seconds, which is
-interpreted in a driver-dependent way.
-See the descriptions of
-specific drivers in the
-.Qq Reference Clock Drivers
-page
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp ) .
-.It Cm stratum Ar int
-Specifies the stratum number assigned to the driver, an integer
-between 0 and 15.
-This number overrides the default stratum number
-ordinarily assigned by the driver itself, usually zero.
-.It Cm refid Ar string
-Specifies an ASCII string of from one to four characters which
-defines the reference identifier used by the driver.
-This string
-overrides the default identifier ordinarily assigned by the driver
-itself.
-.It Cm mode Ar int
-Specifies a mode number which is interpreted in a
-device-specific fashion.
-For instance, it selects a dialing
-protocol in the ACTS driver and a device subtype in the
-parse
-drivers.
-.It Cm flag1 Cm 0 \&| Cm 1
-.It Cm flag2 Cm 0 \&| Cm 1
-.It Cm flag3 Cm 0 \&| Cm 1
-.It Cm flag4 Cm 0 \&| Cm 1
-These four flags are used for customizing the clock driver.
-The
-interpretation of these values, and whether they are used at all,
-is a function of the particular clock driver.
-However, by
-convention
-.Cm flag4
-is used to enable recording monitoring
-data to the
-.Cm clockstats
-file configured with the
-.Ic filegen
-command.
-Further information on the
-.Ic filegen
-command can be found in
-.Sx Monitoring Options .
-.El
-.El
-.Sh Miscellaneous Options
-.Bl -tag -width indent
-.It Ic broadcastdelay Ar seconds
-The broadcast and multicast modes require a special calibration
-to determine the network delay between the local and remote
-servers.
-Ordinarily, this is done automatically by the initial
-protocol exchanges between the client and server.
-In some cases,
-the calibration procedure may fail due to network or server access
-controls, for example.
-This command specifies the default delay to
-be used under these circumstances.
-Typically (for Ethernet), a
-number between 0.003 and 0.007 seconds is appropriate.
-The default
-when this command is not used is 0.004 seconds.
-.It Ic calldelay Ar delay
-This option controls the delay in seconds between the first and second
-packets sent in burst or iburst mode to allow additional time for a modem
-or ISDN call to complete.
-.It Ic driftfile Ar driftfile
-This command specifies the complete path and name of the file used to
-record the frequency of the local clock oscillator.
-This is the same
-operation as the
-.Fl f
-command line option.
-If the file exists, it is read at
-startup in order to set the initial frequency and then updated once per
-hour with the current frequency computed by the daemon.
-If the file name is
-specified, but the file itself does not exist, the starts with an initial
-frequency of zero and creates the file when writing it for the first time.
-If this command is not given, the daemon will always start with an initial
-frequency of zero.
-.Pp
-The file format consists of a single line containing a single
-floating point number, which records the frequency offset measured
-in parts-per-million (PPM).
-The file is updated by first writing
-the current drift value into a temporary file and then renaming
-this file to replace the old version.
-This implies that
-.Xr ntpd @NTPD_MS@
-must have write permission for the directory the
-drift file is located in, and that file system links, symbolic or
-otherwise, should be avoided.
-.It Xo Ic enable
-.Oo
-.Cm auth | Cm bclient |
-.Cm calibrate | Cm kernel |
-.Cm monitor | Cm ntp |
-.Cm pps | Cm stats
-.Oc
-.Xc
-.It Xo Ic disable
-.Oo
-.Cm auth | Cm bclient |
-.Cm calibrate | Cm kernel |
-.Cm monitor | Cm ntp |
-.Cm pps | Cm stats
-.Oc
-.Xc
-Provides a way to enable or disable various server options.
-Flags not mentioned are unaffected.
-Note that all of these flags
-can be controlled remotely using the
-.Xr ntpdc @NTPDC_MS@
-utility program.
-.Bl -tag -width indent
-.It Cm auth
-Enables the server to synchronize with unconfigured peers only if the
-peer has been correctly authenticated using either public key or
-private key cryptography.
-The default for this flag is
-.Ic enable .
-.It Cm bclient
-Enables the server to listen for a message from a broadcast or
-multicast server, as in the
-.Ic multicastclient
-command with default
-address.
-The default for this flag is
-.Ic disable .
-.It Cm calibrate
-Enables the calibrate feature for reference clocks.
-The default for
-this flag is
-.Ic disable .
-.It Cm kernel
-Enables the kernel time discipline, if available.
-The default for this
-flag is
-.Ic enable
-if support is available, otherwise
-.Ic disable .
-.It Cm monitor
-Enables the monitoring facility.
-See the
-.Xr ntpdc @NTPDC_MS@
-program
-and the
-.Ic monlist
-command or further information.
-The
-default for this flag is
-.Ic enable .
-.It Cm ntp
-Enables time and frequency discipline.
-In effect, this switch opens and
-closes the feedback loop, which is useful for testing.
-The default for
-this flag is
-.Ic enable .
-.It Cm pps
-Enables the pulse-per-second (PPS) signal when frequency and time is
-disciplined by the precision time kernel modifications.
-See the
-.Qq A Kernel Model for Precision Timekeeping
-(available as part of the HTML documentation
-provided in
-.Pa /usr/share/doc/ntp )
-page for further information.
-The default for this flag is
-.Ic disable .
-.It Cm stats
-Enables the statistics facility.
-See the
-.Sx Monitoring Options
-section for further information.
-The default for this flag is
-.Ic disable .
-.El
-.It Ic includefile Ar includefile
-This command allows additional configuration commands
-to be included from a separate file.
-Include files may
-be nested to a depth of five; upon reaching the end of any
-include file, command processing resumes in the previous
-configuration file.
-This option is useful for sites that run
-.Xr ntpd @NTPD_MS@
-on multiple hosts, with (mostly) common options (e.g., a
-restriction list).
-.It Ic logconfig Ar configkeyword
-This command controls the amount and type of output written to
-the system
-.Xr syslog 3
-facility or the alternate
-.Ic logfile
-log file.
-By default, all output is turned on.
-All
-.Ar configkeyword
-keywords can be prefixed with
-.Ql = ,
-.Ql +
-and
-.Ql - ,
-where
-.Ql =
-sets the
-.Xr syslog 3
-priority mask,
-.Ql +
-adds and
-.Ql -
-removes
-messages.
-.Xr syslog 3
-messages can be controlled in four
-classes
-.Po
-.Cm clock ,
-.Cm peer ,
-.Cm sys
-and
-.Cm sync
-.Pc .
-Within these classes four types of messages can be
-controlled: informational messages
-.Po
-.Cm info
-.Pc ,
-event messages
-.Po
-.Cm events
-.Pc ,
-statistics messages
-.Po
-.Cm statistics
-.Pc
-and
-status messages
-.Po
-.Cm status
-.Pc .
-.Pp
-Configuration keywords are formed by concatenating the message class with
-the event class.
-The
-.Cm all
-prefix can be used instead of a message class.
-A
-message class may also be followed by the
-.Cm all
-keyword to enable/disable all
-messages of the respective message class.Thus, a minimal log configuration
-could look like this:
-.Bd -literal
-logconfig =syncstatus +sysevents
-.Ed
-.Pp
-This would just list the synchronizations state of
-.Xr ntpd @NTPD_MS@
-and the major system events.
-For a simple reference server, the
-following minimum message configuration could be useful:
-.Bd -literal
-logconfig =syncall +clockall
-.Ed
-.Pp
-This configuration will list all clock information and
-synchronization information.
-All other events and messages about
-peers, system events and so on is suppressed.
-.It Ic logfile Ar logfile
-This command specifies the location of an alternate log file to
-be used instead of the default system
-.Xr syslog 3
-facility.
-This is the same operation as the -l command line option.
-.It Ic setvar Ar variable Op Cm default
-This command adds an additional system variable.
-These
-variables can be used to distribute additional information such as
-the access policy.
-If the variable of the form
-.Sm off
-.Va name = Ar value
-.Sm on
-is followed by the
-.Cm default
-keyword, the
-variable will be listed as part of the default system variables
-.Po
-.Xr ntpq @NTPQ_MS@
-.Ic rv
-command
-.Pc ) .
-These additional variables serve
-informational purposes only.
-They are not related to the protocol
-other that they can be listed.
-The known protocol variables will
-always override any variables defined via the
-.Ic setvar
-mechanism.
-There are three special variables that contain the names
-of all variable of the same group.
-The
-.Va sys_var_list
-holds
-the names of all system variables.
-The
-.Va peer_var_list
-holds
-the names of all peer variables and the
-.Va clock_var_list
-holds the names of the reference clock variables.
-.It Xo Ic tinker
-.Oo
-.Cm allan Ar allan |
-.Cm dispersion Ar dispersion |
-.Cm freq Ar freq |
-.Cm huffpuff Ar huffpuff |
-.Cm panic Ar panic |
-.Cm step Ar srep |
-.Cm stepout Ar stepout
-.Oc
-.Xc
-This command can be used to alter several system variables in
-very exceptional circumstances.
-It should occur in the
-configuration file before any other configuration options.
-The
-default values of these variables have been carefully optimized for
-a wide range of network speeds and reliability expectations.
-In
-general, they interact in intricate ways that are hard to predict
-and some combinations can result in some very nasty behavior.
-Very
-rarely is it necessary to change the default values; but, some
-folks cannot resist twisting the knobs anyway and this command is
-for them.
-Emphasis added: twisters are on their own and can expect
-no help from the support group.
-.Pp
-The variables operate as follows:
-.Bl -tag -width indent
-.It Cm allan Ar allan
-The argument becomes the new value for the minimum Allan
-intercept, which is a parameter of the PLL/FLL clock discipline
-algorithm.
-The value in log2 seconds defaults to 7 (1024 s), which is also the lower
-limit.
-.It Cm dispersion Ar dispersion
-The argument becomes the new value for the dispersion increase rate,
-normally .000015 s/s.
-.It Cm freq Ar freq
-The argument becomes the initial value of the frequency offset in
-parts-per-million.
-This overrides the value in the frequency file, if
-present, and avoids the initial training state if it is not.
-.It Cm huffpuff Ar huffpuff
-The argument becomes the new value for the experimental
-huff-n'-puff filter span, which determines the most recent interval
-the algorithm will search for a minimum delay.
-The lower limit is
-900 s (15 m), but a more reasonable value is 7200 (2 hours).
-There
-is no default, since the filter is not enabled unless this command
-is given.
-.It Cm panic Ar panic
-The argument is the panic threshold, normally 1000 s.
-If set to zero,
-the panic sanity check is disabled and a clock offset of any value will
-be accepted.
-.It Cm step Ar step
-The argument is the step threshold, which by default is 0.128 s.
-It can
-be set to any positive number in seconds.
-If set to zero, step
-adjustments will never occur.
-Note: The kernel time discipline is
-disabled if the step threshold is set to zero or greater than the
-default.
-.It Cm stepout Ar stepout
-The argument is the stepout timeout, which by default is 900 s.
-It can
-be set to any positive number in seconds.
-If set to zero, the stepout
-pulses will not be suppressed.
-.El
-.It Xo Ic trap Ar host_address
-.Op Cm port Ar port_number
-.Op Cm interface Ar interface_address
-.Xc
-This command configures a trap receiver at the given host
-address and port number for sending messages with the specified
-local interface address.
-If the port number is unspecified, a value
-of 18447 is used.
-If the interface address is not specified, the
-message is sent with a source address of the local interface the
-message is sent through.
-Note that on a multihomed host the
-interface used may vary from time to time with routing changes.
-.Pp
-The trap receiver will generally log event messages and other
-information from the server in a log file.
-While such monitor
-programs may also request their own trap dynamically, configuring a
-trap receiver will ensure that no messages are lost when the server
-is started.
-.It Cm hop Ar ...
-This command specifies a list of TTL values in increasing order, up to 8
-values can be specified.
-In manycast mode these values are used in turn in
-an expanding-ring search.
-The default is eight multiples of 32 starting at
-31.
-.El
.Sh FILES
-.Bl -tag -width /etc/ntp.drift -compact
-.It Pa /etc/ntp.conf
-the default name of the configuration file
-.It Pa ntp.keys
-private MD5 keys
-.It Pa ntpkey
-RSA private key
-.It Pa ntpkey_ Ns Ar host
-RSA public key
-.It Pa ntp_dh
-Diffie-Hellman agreement parameters
-.El
.Sh "SEE ALSO"
-.Sh SEE ALSO
-.Xr ntpd @NTPD_MS@ ,
-.Xr ntpdc @NTPDC_MS@ ,
-.Xr ntpq @NTPQ_MS@
-.Pp
-In addition to the manual pages provided,
-comprehensive documentation is available on the world wide web
-at
-.Li http://www.ntp.org/ .
-A snapshot of this documentation is available in HTML format in
-.Pa /usr/share/doc/ntp .
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 4)
-.%O RFC5905
-.Re
.Sh "AUTHORS"
The University of Delaware
.Sh "COPYRIGHT"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.Sh BUGS
-The syntax checking is not picky; some combinations of
-ridiculous and even hilarious options and modes may not be
-detected.
-.Pp
-The
-.Pa ntpkey_ Ns Ar host
-files are really digital
-certificates.
-These should be obtained via secure directory
-services when they become universally available.Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
+Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.Sh NOTES
-This document is derived from FreeBSD.
.Pp
This manual page was \fIAutoGen\fP-erated from the \fBntp.conf\fP
option definitions.
-.TH ntp.keys 5man "05 Dec 2012" "4.2.7p331" "File Formats"
+.TH ntp.keys 5man "06 Dec 2012" "4.2.7p332" "File Formats"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp.man)
.\"
-.\" It has been AutoGen-ed December 5, 2012 at 10:46:07 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:11 AM by AutoGen 5.16.2
.\" From the definitions ntp.keys.def
.\" and the template file agman-file.tpl
.\"
.PP
.PP
.SH DESCRIPTION
-This document describes the format of an NTP symmetric key file.
-For a description of the use of this type of file, see the
-.Qq Authentication Support
-section of the
-.Xr ntp.conf 5
-page.
-.PP
-.Xr ntpd 8
-reads its keys from a file specified using the
-k
-command line option or the
-.Ic keys
-statement in the configuration file.
-While key number 0 is fixed by the NTP standard
-(as 56 zero bits)
-and may not be changed,
-one or more keys numbered between 1 and 65534
-may be arbitrarily set in the keys file.
-.PP
-The key file uses the same comment conventions
-as the configuration file.
-Key entries use a fixed format of the form
-.PP
-.D1 Ar keyno type key
-.PP
-where
-\fIkeyno\fR
-is a positive integer (between 1 and 65534),
-\fItype\fR
-is the message digest algorithm,
-and
-\fIkey\fR
-is the key itself.
-.PP
-The
-\fIkey\fR
-may be given in a format
-controlled by the
-\fItype\fR
-field.
-The
-\fItype\fR
-.Li MD5
-is always supported.
-If
-.Li ntpd
-was built with the OpenSSL library
-then any digest library supported by that library may be specified.
-However, if compliance with FIPS 140-2 is required the
-\fItype\fR
-must be either
-.Li SHA
-or
-.Li SHA1 .
-.PP
-What follows are some key types, and corresponding formats:
-.PP
-.TP
-.BR Li MD5
-The key is 1 to 16 printable characters terminated by
-an EOL,
-whitespace,
-or
-a
-.Li #
-(which is the "start of comment" character).
-.PP
-.TP
-.BR Li SHA
-.TP
-.BR Li SHA1
-.TP
-.BR Li RMD160
-The key is a hex-encoded ASCII string of 40 characters,
-which is truncated as necessary.
-.PP
-Note that the keys used by the
-.Xr ntpq 8
-and
-.Xr ntpdc 8
-programs are checked against passwords
-requested by the programs and entered by hand,
-so it is generally appropriate to specify these keys in ASCII format.
.SH FILES
-.TP
-.BR Pa /etc/ntp.keys
-the default name of the configuration file
.SH "SEE ALSO"
-.Xr ntp.conf 5 ,
-.Xr ntpd 1ntpdmdoc ,
-.Xr ntpdate 1ntpdatemdoc ,
-.Xr ntpdc 1ntpdcmdoc ,
-.Xr sntp 1sntpmdoc
.SH "AUTHORS"
The University of Delaware
.SH "COPYRIGHT"
.SH "BUGS"
Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.SH NOTES
-This document is derived from FreeBSD.
.PP
This manual page was \fIAutoGen\fP-erated from the \fBntp.keys\fP
option definitions.
-.Dd December 5 2012
+.Dd December 6 2012
.Dt NTP_KEYS 5mdoc File Formats
-.Os FreeBSD 6.4-STABLE
+.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp.mdoc)
.\"
-.\" It has been AutoGen-ed December 5, 2012 at 10:45:55 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:27 AM by AutoGen 5.16.2
.\" From the definitions ntp.keys.def
.\" and the template file agmdoc-file.tpl
.Sh NAME
.Sy /etc/ntp.keys
.Pp
.Sh DESCRIPTION
-This document describes the format of an NTP symmetric key file.
-For a description of the use of this type of file, see the
-.Qq Authentication Support
-section of the
-.Xr ntp.conf 5
-page.
-.Pp
-.Xr ntpd 8
-reads its keys from a file specified using the
-.Fl k
-command line option or the
-.Ic keys
-statement in the configuration file.
-While key number 0 is fixed by the NTP standard
-(as 56 zero bits)
-and may not be changed,
-one or more keys numbered between 1 and 65534
-may be arbitrarily set in the keys file.
-.Pp
-The key file uses the same comment conventions
-as the configuration file.
-Key entries use a fixed format of the form
-.Pp
-.D1 Ar keyno type key
-.Pp
-where
-.Ar keyno
-is a positive integer (between 1 and 65534),
-.Ar type
-is the message digest algorithm,
-and
-.Ar key
-is the key itself.
-.Pp
-The
-.Ar key
-may be given in a format
-controlled by the
-.Ar type
-field.
-The
-.Ar type
-.Li MD5
-is always supported.
-If
-.Li ntpd
-was built with the OpenSSL library
-then any digest library supported by that library may be specified.
-However, if compliance with FIPS 140-2 is required the
-.Ar type
-must be either
-.Li SHA
-or
-.Li SHA1 .
-.Pp
-What follows are some key types, and corresponding formats:
-.Pp
-.Bl -tag -width RMD160 -compact
-.It Li MD5
-The key is 1 to 16 printable characters terminated by
-an EOL,
-whitespace,
-or
-a
-.Li #
-(which is the "start of comment" character).
-.Pp
-.It Li SHA
-.It Li SHA1
-.It Li RMD160
-The key is a hex-encoded ASCII string of 40 characters,
-which is truncated as necessary.
-.El
-.Pp
-Note that the keys used by the
-.Xr ntpq 8
-and
-.Xr ntpdc 8
-programs are checked against passwords
-requested by the programs and entered by hand,
-so it is generally appropriate to specify these keys in ASCII format.
.Sh FILES
-.Bl -tag -width /etc/ntp.keys -compact
-.It Pa /etc/ntp.keys
-the default name of the configuration file
-.El
.Sh "SEE ALSO"
-.Xr ntp.conf 5 ,
-.Xr ntpd 1ntpdmdoc ,
-.Xr ntpdate 1ntpdatemdoc ,
-.Xr ntpdc 1ntpdcmdoc ,
-.Xr sntp 1sntpmdoc
.Sh "AUTHORS"
The University of Delaware
.Sh "COPYRIGHT"
.Sh "BUGS"
Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.Sh NOTES
-This document is derived from FreeBSD.
.Pp
This manual page was \fIAutoGen\fP-erated from the \fBntp.keys\fP
option definitions.
<p>This document describes the symmetric key file for the NTP Project's
<code>ntpd</code> program.
- <p>This document applies to version 4.2.7p331 of <code>ntp.keys</code>.
+ <p>This document applies to version 4.2.7p332 of <code>ntp.keys</code>.
<div class="shortcontents">
<h2>Short Contents</h2>
-.TH ntp.keys 5 "05 Dec 2012" "4.2.7p331" "File Formats"
+.TH ntp.keys 5 "06 Dec 2012" "4.2.7p332" "File Formats"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp.man)
.\"
-.\" It has been AutoGen-ed December 5, 2012 at 10:46:07 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:11 AM by AutoGen 5.16.2
.\" From the definitions ntp.keys.def
.\" and the template file agman-file.tpl
.\"
.PP
.PP
.SH DESCRIPTION
-This document describes the format of an NTP symmetric key file.
-For a description of the use of this type of file, see the
-.Qq Authentication Support
-section of the
-.Xr ntp.conf 5
-page.
-.PP
-.Xr ntpd 8
-reads its keys from a file specified using the
-k
-command line option or the
-.Ic keys
-statement in the configuration file.
-While key number 0 is fixed by the NTP standard
-(as 56 zero bits)
-and may not be changed,
-one or more keys numbered between 1 and 65534
-may be arbitrarily set in the keys file.
-.PP
-The key file uses the same comment conventions
-as the configuration file.
-Key entries use a fixed format of the form
-.PP
-.D1 Ar keyno type key
-.PP
-where
-\fIkeyno\fR
-is a positive integer (between 1 and 65534),
-\fItype\fR
-is the message digest algorithm,
-and
-\fIkey\fR
-is the key itself.
-.PP
-The
-\fIkey\fR
-may be given in a format
-controlled by the
-\fItype\fR
-field.
-The
-\fItype\fR
-.Li MD5
-is always supported.
-If
-.Li ntpd
-was built with the OpenSSL library
-then any digest library supported by that library may be specified.
-However, if compliance with FIPS 140-2 is required the
-\fItype\fR
-must be either
-.Li SHA
-or
-.Li SHA1 .
-.PP
-What follows are some key types, and corresponding formats:
-.PP
-.TP
-.BR Li MD5
-The key is 1 to 16 printable characters terminated by
-an EOL,
-whitespace,
-or
-a
-.Li #
-(which is the "start of comment" character).
-.PP
-.TP
-.BR Li SHA
-.TP
-.BR Li SHA1
-.TP
-.BR Li RMD160
-The key is a hex-encoded ASCII string of 40 characters,
-which is truncated as necessary.
-.PP
-Note that the keys used by the
-.Xr ntpq 8
-and
-.Xr ntpdc 8
-programs are checked against passwords
-requested by the programs and entered by hand,
-so it is generally appropriate to specify these keys in ASCII format.
.SH FILES
-.TP
-.BR Pa /etc/ntp.keys
-the default name of the configuration file
.SH "SEE ALSO"
-.Xr ntp.conf 5 ,
-.Xr ntpd @NTPD_MS@ ,
-.Xr ntpdate @NTPDATE_MS@ ,
-.Xr ntpdc @NTPDC_MS@ ,
-.Xr sntp @SNTP_MS@
.SH "AUTHORS"
The University of Delaware
.SH "COPYRIGHT"
.SH "BUGS"
Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.SH NOTES
-This document is derived from FreeBSD.
.PP
This manual page was \fIAutoGen\fP-erated from the \fBntp.keys\fP
option definitions.
-.Dd December 5 2012
+.Dd December 6 2012
.Dt NTP_KEYS 5 File Formats
-.Os FreeBSD 6.4-STABLE
+.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp.mdoc)
.\"
-.\" It has been AutoGen-ed December 5, 2012 at 10:45:55 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:27 AM by AutoGen 5.16.2
.\" From the definitions ntp.keys.def
.\" and the template file agmdoc-file.tpl
.Sh NAME
.Sy /etc/ntp.keys
.Pp
.Sh DESCRIPTION
-This document describes the format of an NTP symmetric key file.
-For a description of the use of this type of file, see the
-.Qq Authentication Support
-section of the
-.Xr ntp.conf 5
-page.
-.Pp
-.Xr ntpd 8
-reads its keys from a file specified using the
-.Fl k
-command line option or the
-.Ic keys
-statement in the configuration file.
-While key number 0 is fixed by the NTP standard
-(as 56 zero bits)
-and may not be changed,
-one or more keys numbered between 1 and 65534
-may be arbitrarily set in the keys file.
-.Pp
-The key file uses the same comment conventions
-as the configuration file.
-Key entries use a fixed format of the form
-.Pp
-.D1 Ar keyno type key
-.Pp
-where
-.Ar keyno
-is a positive integer (between 1 and 65534),
-.Ar type
-is the message digest algorithm,
-and
-.Ar key
-is the key itself.
-.Pp
-The
-.Ar key
-may be given in a format
-controlled by the
-.Ar type
-field.
-The
-.Ar type
-.Li MD5
-is always supported.
-If
-.Li ntpd
-was built with the OpenSSL library
-then any digest library supported by that library may be specified.
-However, if compliance with FIPS 140-2 is required the
-.Ar type
-must be either
-.Li SHA
-or
-.Li SHA1 .
-.Pp
-What follows are some key types, and corresponding formats:
-.Pp
-.Bl -tag -width RMD160 -compact
-.It Li MD5
-The key is 1 to 16 printable characters terminated by
-an EOL,
-whitespace,
-or
-a
-.Li #
-(which is the "start of comment" character).
-.Pp
-.It Li SHA
-.It Li SHA1
-.It Li RMD160
-The key is a hex-encoded ASCII string of 40 characters,
-which is truncated as necessary.
-.El
-.Pp
-Note that the keys used by the
-.Xr ntpq 8
-and
-.Xr ntpdc 8
-programs are checked against passwords
-requested by the programs and entered by hand,
-so it is generally appropriate to specify these keys in ASCII format.
.Sh FILES
-.Bl -tag -width /etc/ntp.keys -compact
-.It Pa /etc/ntp.keys
-the default name of the configuration file
-.El
.Sh "SEE ALSO"
-.Xr ntp.conf 5 ,
-.Xr ntpd @NTPD_MS@ ,
-.Xr ntpdate @NTPDATE_MS@ ,
-.Xr ntpdc @NTPDC_MS@ ,
-.Xr sntp @SNTP_MS@
.Sh "AUTHORS"
The University of Delaware
.Sh "COPYRIGHT"
.Sh "BUGS"
Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.Sh NOTES
-This document is derived from FreeBSD.
.Pp
This manual page was \fIAutoGen\fP-erated from the \fBntp.keys\fP
option definitions.
/*
* EDIT THIS FILE WITH CAUTION (ntpd-opts.c)
*
- * It has been AutoGen-ed December 3, 2012 at 11:40:31 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 6, 2012 at 07:43:19 AM by AutoGen 5.16.2
* From the definitions ntpd-opts.def
* and the template file options
*
* ntpd option static const strings
*/
static char const ntpd_opt_strs[2987] =
-/* 0 */ "ntpd 4.2.7p331\n"
+/* 0 */ "ntpd 4.2.7p332\n"
"Copyright (C) 1970-2012 The University of Delaware, all rights reserved.\n"
"This is free software. It is licensed for use, modification and\n"
"redistribution under the terms of the NTP License, copies of which\n"
/* 2753 */ "Output version information and exit\0"
/* 2789 */ "version\0"
/* 2797 */ "NTPD\0"
-/* 2802 */ "ntpd - NTP daemon program - Ver. 4.2.7p331\n"
+/* 2802 */ "ntpd - NTP daemon program - Ver. 4.2.7p332\n"
"USAGE: %s [ -<flag> [<val>] | --<name>[{=| }<val>] ]... \\\n"
"\t\t[ <server1> ... <serverN> ]\n\0"
/* 2935 */ "http://bugs.ntp.org, bugs@ntp.org\0"
/* 2969 */ "\n\n\0"
-/* 2972 */ "ntpd 4.2.7p331";
+/* 2972 */ "ntpd 4.2.7p332";
/*
* ipv4 option description with
/*
* EDIT THIS FILE WITH CAUTION (ntpd-opts.h)
*
- * It has been AutoGen-ed December 3, 2012 at 11:40:30 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 6, 2012 at 07:43:18 AM by AutoGen 5.16.2
* From the definitions ntpd-opts.def
* and the template file options
*
} teOptIndex;
#define OPTION_CT 37
-#define NTPD_VERSION "4.2.7p331"
-#define NTPD_FULL_VERSION "ntpd 4.2.7p331"
+#define NTPD_VERSION "4.2.7p332"
+#define NTPD_FULL_VERSION "ntpd 4.2.7p332"
/*
* Interface defines for all options. Replace "n" with the UPPER_CASED
-.TH ntpd 1ntpdman "03 Dec 2012" "4.2.7p331" "User Commands"
+.TH ntpd 1ntpdman "06 Dec 2012" "4.2.7p332" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpd-opts.man)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:41:23 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:14 AM by AutoGen 5.16.2
.\" From the definitions ntpd-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 3 2012
+.Dd December 6 2012
.Dt NTPD 1ntpdmdoc User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpd-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:41:38 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:29 AM by AutoGen 5.16.2
.\" From the definitions ntpd-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
-.TH ntpd @NTPD_MS@ "03 Dec 2012" "4.2.7p331" "User Commands"
+.TH ntpd @NTPD_MS@ "06 Dec 2012" "4.2.7p332" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpd-opts.man)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:41:23 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:14 AM by AutoGen 5.16.2
.\" From the definitions ntpd-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 3 2012
+.Dd December 6 2012
.Dt NTPD @NTPD_MS@ User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpd-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:41:38 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:29 AM by AutoGen 5.16.2
.\" From the definitions ntpd-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
#
# EDIT THIS FILE WITH CAUTION (invoke-ntpdc.texi)
#
-# It has been AutoGen-ed December 3, 2012 at 11:41:58 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 6, 2012 at 07:44:48 AM by AutoGen 5.16.2
# From the definitions ntpdc-opts.def
# and the template file agtexi-cmd.tpl
@end ignore
@exampleindent 0
@example
-ntpdc - vendor-specific NTPD control program - Ver. 4.2.7p331
+ntpdc - vendor-specific NTPD control program - Ver. 4.2.7p332
USAGE: ntpdc [ -<flag> [<val>] | --<name>[@{=| @}<val>] ]... [ host ...]
Flg Arg Option-Name Description
-4 no ipv4 Force IPv4 DNS name resolution
/*
* EDIT THIS FILE WITH CAUTION (ntpdc-opts.c)
*
- * It has been AutoGen-ed December 3, 2012 at 11:41:49 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 6, 2012 at 07:44:39 AM by AutoGen 5.16.2
* From the definitions ntpdc-opts.def
* and the template file options
*
* ntpdc option static const strings
*/
static char const ntpdc_opt_strs[1862] =
-/* 0 */ "ntpdc 4.2.7p331\n"
+/* 0 */ "ntpdc 4.2.7p332\n"
"Copyright (C) 1970-2012 The University of Delaware, all rights reserved.\n"
"This is free software. It is licensed for use, modification and\n"
"redistribution under the terms of the NTP License, copies of which\n"
/* 1640 */ "no-load-opts\0"
/* 1653 */ "no\0"
/* 1656 */ "NTPDC\0"
-/* 1662 */ "ntpdc - vendor-specific NTPD control program - Ver. 4.2.7p331\n"
+/* 1662 */ "ntpdc - vendor-specific NTPD control program - Ver. 4.2.7p332\n"
"USAGE: %s [ -<flag> [<val>] | --<name>[{=| }<val>] ]... [ host ...]\n\0"
/* 1794 */ "$HOME\0"
/* 1800 */ ".\0"
/* 1802 */ ".ntprc\0"
/* 1809 */ "http://bugs.ntp.org, bugs@ntp.org\0"
/* 1843 */ "\n\n\0"
-/* 1846 */ "ntpdc 4.2.7p331";
+/* 1846 */ "ntpdc 4.2.7p332";
/*
* ipv4 option description with
/*
* EDIT THIS FILE WITH CAUTION (ntpdc-opts.h)
*
- * It has been AutoGen-ed December 3, 2012 at 11:41:48 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 6, 2012 at 07:44:38 AM by AutoGen 5.16.2
* From the definitions ntpdc-opts.def
* and the template file options
*
} teOptIndex;
#define OPTION_CT 15
-#define NTPDC_VERSION "4.2.7p331"
-#define NTPDC_FULL_VERSION "ntpdc 4.2.7p331"
+#define NTPDC_VERSION "4.2.7p332"
+#define NTPDC_FULL_VERSION "ntpdc 4.2.7p332"
/*
* Interface defines for all options. Replace "n" with the UPPER_CASED
-.TH ntpdc 1ntpdcman "03 Dec 2012" "4.2.7p331" "User Commands"
+.TH ntpdc 1ntpdcman "06 Dec 2012" "4.2.7p332" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpdc-opts.man)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:41:54 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:44 AM by AutoGen 5.16.2
.\" From the definitions ntpdc-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 3 2012
+.Dd December 6 2012
.Dt NTPDC 1ntpdcmdoc User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpdc-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:42:00 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:50 AM by AutoGen 5.16.2
.\" From the definitions ntpdc-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
clock. Run as root, it can correct the system clock to this offset as
well. It can be run as an interactive command or from a cron job.
- <p>This document applies to version 4.2.7p331 of <code>ntpdc</code>.
+ <p>This document applies to version 4.2.7p332 of <code>ntpdc</code>.
<p>The program implements the SNTP protocol as defined by RFC 5905, the NTPv4
IETF specification.
used to select the program, defaulting to <span class="file">more</span>. Both will exit
with a status code of 0.
-<pre class="example">ntpdc - vendor-specific NTPD control program - Ver. 4.2.7p331
+<pre class="example">ntpdc - vendor-specific NTPD control program - Ver. 4.2.7p332
USAGE: ntpdc [ -<flag> [<val>] | --<name>[{=| }<val>] ]... [ host ...]
Flg Arg Option-Name Description
-4 no ipv4 Force IPv4 DNS name resolution
-.TH ntpdc @NTPDC_MS@ "03 Dec 2012" "4.2.7p331" "User Commands"
+.TH ntpdc @NTPDC_MS@ "06 Dec 2012" "4.2.7p332" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpdc-opts.man)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:41:54 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:44 AM by AutoGen 5.16.2
.\" From the definitions ntpdc-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 3 2012
+.Dd December 6 2012
.Dt NTPDC @NTPDC_MS@ User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpdc-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:42:00 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:44:50 AM by AutoGen 5.16.2
.\" From the definitions ntpdc-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
#
# EDIT THIS FILE WITH CAUTION (invoke-ntpq.texi)
#
-# It has been AutoGen-ed December 3, 2012 at 11:42:14 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 6, 2012 at 07:45:04 AM by AutoGen 5.16.2
# From the definitions ntpq-opts.def
# and the template file agtexi-cmd.tpl
@end ignore
@exampleindent 0
@example
-ntpq - standard NTP query program - Ver. 4.2.7p331
+ntpq - standard NTP query program - Ver. 4.2.7p332
USAGE: ntpq [ -<flag> [<val>] | --<name>[@{=| @}<val>] ]... [ host ...]
Flg Arg Option-Name Description
-4 no ipv4 Force IPv4 DNS name resolution
/*
* EDIT THIS FILE WITH CAUTION (ntpq-opts.c)
*
- * It has been AutoGen-ed December 3, 2012 at 11:42:03 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 6, 2012 at 07:44:53 AM by AutoGen 5.16.2
* From the definitions ntpq-opts.def
* and the template file options
*
* ntpq option static const strings
*/
static char const ntpq_opt_strs[1833] =
-/* 0 */ "ntpq 4.2.7p331\n"
+/* 0 */ "ntpq 4.2.7p332\n"
"Copyright (C) 1970-2012 The University of Delaware, all rights reserved.\n"
"This is free software. It is licensed for use, modification and\n"
"redistribution under the terms of the NTP License, copies of which\n"
/* 1627 */ "no-load-opts\0"
/* 1640 */ "no\0"
/* 1643 */ "NTPQ\0"
-/* 1648 */ "ntpq - standard NTP query program - Ver. 4.2.7p331\n"
+/* 1648 */ "ntpq - standard NTP query program - Ver. 4.2.7p332\n"
"USAGE: %s [ -<flag> [<val>] | --<name>[{=| }<val>] ]... [ host ...]\n\0"
/* 1769 */ "$HOME\0"
/* 1775 */ ".\0"
/* 1777 */ ".ntprc\0"
/* 1784 */ "http://bugs.ntp.org, bugs@ntp.org\0"
-/* 1818 */ "ntpq 4.2.7p331";
+/* 1818 */ "ntpq 4.2.7p332";
/*
* ipv4 option description with
/*
* EDIT THIS FILE WITH CAUTION (ntpq-opts.h)
*
- * It has been AutoGen-ed December 3, 2012 at 11:42:02 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 6, 2012 at 07:44:53 AM by AutoGen 5.16.2
* From the definitions ntpq-opts.def
* and the template file options
*
} teOptIndex;
#define OPTION_CT 14
-#define NTPQ_VERSION "4.2.7p331"
-#define NTPQ_FULL_VERSION "ntpq 4.2.7p331"
+#define NTPQ_VERSION "4.2.7p332"
+#define NTPQ_FULL_VERSION "ntpq 4.2.7p332"
/*
* Interface defines for all options. Replace "n" with the UPPER_CASED
-.TH ntpq 1ntpqman "03 Dec 2012" "4.2.7p331" "User Commands"
+.TH ntpq 1ntpqman "06 Dec 2012" "4.2.7p332" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpq-opts.man)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:42:10 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:45:00 AM by AutoGen 5.16.2
.\" From the definitions ntpq-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 3 2012
+.Dd December 6 2012
.Dt NTPQ 1ntpqmdoc User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpq-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:42:15 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:45:06 AM by AutoGen 5.16.2
.\" From the definitions ntpq-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
-.TH ntpq @NTPQ_MS@ "03 Dec 2012" "4.2.7p331" "User Commands"
+.TH ntpq @NTPQ_MS@ "06 Dec 2012" "4.2.7p332" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpq-opts.man)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:42:10 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:45:00 AM by AutoGen 5.16.2
.\" From the definitions ntpq-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 3 2012
+.Dd December 6 2012
.Dt NTPQ @NTPQ_MS@ User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpq-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:42:15 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:45:06 AM by AutoGen 5.16.2
.\" From the definitions ntpq-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
#
# EDIT THIS FILE WITH CAUTION (invoke-ntpsnmpd.texi)
#
-# It has been AutoGen-ed December 3, 2012 at 11:42:29 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 6, 2012 at 07:45:19 AM by AutoGen 5.16.2
# From the definitions ntpsnmpd-opts.def
# and the template file agtexi-cmd.tpl
@end ignore
@exampleindent 0
@example
-ntpsnmpd - NTP SNMP MIB agent - Ver. 4.2.7p331
+ntpsnmpd - NTP SNMP MIB agent - Ver. 4.2.7p332
USAGE: ntpsnmpd [ -<flag> [<val>] | --<name>[@{=| @}<val>] ]...
Flg Arg Option-Name Description
-n no nofork Do not fork
/*
* EDIT THIS FILE WITH CAUTION (ntpsnmpd-opts.c)
*
- * It has been AutoGen-ed December 3, 2012 at 11:42:18 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 6, 2012 at 07:45:08 AM by AutoGen 5.16.2
* From the definitions ntpsnmpd-opts.def
* and the template file options
*
* ntpsnmpd option static const strings
*/
static char const ntpsnmpd_opt_strs[1561] =
-/* 0 */ "ntpsnmpd 4.2.7p331\n"
+/* 0 */ "ntpsnmpd 4.2.7p332\n"
"Copyright (C) 1970-2012 The University of Delaware, all rights reserved.\n"
"This is free software. It is licensed for use, modification and\n"
"redistribution under the terms of the NTP License, copies of which\n"
/* 1360 */ "no-load-opts\0"
/* 1373 */ "no\0"
/* 1376 */ "NTPSNMPD\0"
-/* 1385 */ "ntpsnmpd - NTP SNMP MIB agent - Ver. 4.2.7p331\n"
+/* 1385 */ "ntpsnmpd - NTP SNMP MIB agent - Ver. 4.2.7p332\n"
"USAGE: %s [ -<flag> [<val>] | --<name>[{=| }<val>] ]...\n\0"
/* 1490 */ "$HOME\0"
/* 1496 */ ".\0"
/* 1498 */ ".ntprc\0"
/* 1505 */ "http://bugs.ntp.org, bugs@ntp.org\0"
/* 1539 */ "\n\n\0"
-/* 1542 */ "ntpsnmpd 4.2.7p331";
+/* 1542 */ "ntpsnmpd 4.2.7p332";
/*
* nofork option description:
/*
* EDIT THIS FILE WITH CAUTION (ntpsnmpd-opts.h)
*
- * It has been AutoGen-ed December 3, 2012 at 11:42:18 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 6, 2012 at 07:45:08 AM by AutoGen 5.16.2
* From the definitions ntpsnmpd-opts.def
* and the template file options
*
} teOptIndex;
#define OPTION_CT 8
-#define NTPSNMPD_VERSION "4.2.7p331"
-#define NTPSNMPD_FULL_VERSION "ntpsnmpd 4.2.7p331"
+#define NTPSNMPD_VERSION "4.2.7p332"
+#define NTPSNMPD_FULL_VERSION "ntpsnmpd 4.2.7p332"
/*
* Interface defines for all options. Replace "n" with the UPPER_CASED
-.TH ntpsnmpd 1ntpsnmpdman "03 Dec 2012" "4.2.7p331" "User Commands"
+.TH ntpsnmpd 1ntpsnmpdman "06 Dec 2012" "4.2.7p332" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpsnmpd-opts.man)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:42:25 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:45:15 AM by AutoGen 5.16.2
.\" From the definitions ntpsnmpd-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 3 2012
+.Dd December 6 2012
.Dt NTPSNMPD 1ntpsnmpdmdoc User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpsnmpd-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:42:31 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:45:21 AM by AutoGen 5.16.2
.\" From the definitions ntpsnmpd-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
-.TH ntpsnmpd @NTPSNMPD_MS@ "03 Dec 2012" "4.2.7p331" "User Commands"
+.TH ntpsnmpd @NTPSNMPD_MS@ "06 Dec 2012" "4.2.7p332" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpsnmpd-opts.man)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:42:25 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:45:15 AM by AutoGen 5.16.2
.\" From the definitions ntpsnmpd-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 3 2012
+.Dd December 6 2012
.Dt NTPSNMPD @NTPSNMPD_MS@ User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpsnmpd-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:42:31 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:45:21 AM by AutoGen 5.16.2
.\" From the definitions ntpsnmpd-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
# - Numeric values increment
# - empty 'increments' to 1
# - NEW 'increments' to empty
-point=331
+point=332
### betapoint is normally modified by script.
# ntp-stable Beta number (betapoint)
#
# EDIT THIS FILE WITH CAUTION (invoke-ntp-wait.texi)
#
-# It has been AutoGen-ed December 3, 2012 at 11:39:39 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 6, 2012 at 07:42:29 AM by AutoGen 5.16.2
# From the definitions ntp-wait-opts.def
# and the template file agtexi-cmd.tpl
@end ignore
-.TH ntp-wait 1ntp-waitman "03 Dec 2012" "ntp (4.2.7p331)" "User Commands"
+.TH ntp-wait 1ntp-waitman "06 Dec 2012" "ntp (4.2.7p332)" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp-wait-opts.man)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:39:36 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:42:25 AM by AutoGen 5.16.2
.\" From the definitions ntp-wait-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 3 2012
+.Dd December 6 2012
.Dt NTP_WAIT 1ntp-waitmdoc User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp-wait-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:39:41 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:42:30 AM by AutoGen 5.16.2
.\" From the definitions ntp-wait-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
clock. Run as root, it can correct the system clock to this offset as
well. It can be run as an interactive command or from a cron job.
- <p>This document applies to version 4.2.7p331 of <code>ntp-wait</code>.
+ <p>This document applies to version 4.2.7p332 of <code>ntp-wait</code>.
<p>The program implements the SNTP protocol as defined by RFC 5905, the NTPv4
IETF specification.
-.TH ntp-wait @NTP_WAIT_MS@ "03 Dec 2012" "ntp (4.2.7p331)" "User Commands"
+.TH ntp-wait @NTP_WAIT_MS@ "06 Dec 2012" "ntp (4.2.7p332)" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp-wait-opts.man)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:39:36 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:42:25 AM by AutoGen 5.16.2
.\" From the definitions ntp-wait-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 3 2012
+.Dd December 6 2012
.Dt NTP_WAIT @NTP_WAIT_MS@ User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp-wait-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:39:41 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:42:30 AM by AutoGen 5.16.2
.\" From the definitions ntp-wait-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
#
# EDIT THIS FILE WITH CAUTION (invoke-sntp.texi)
#
-# It has been AutoGen-ed December 6, 2012 at 02:11:56 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 6, 2012 at 07:46:00 AM by AutoGen 5.16.2
# From the definitions sntp-opts.def
# and the template file agtexi-cmd.tpl
@end ignore
@exampleindent 0
@example
-sntp - standard Simple Network Time Protocol client program - Ver. 4.2.7p331
+sntp - standard Simple Network Time Protocol client program - Ver. 4.2.7p332
USAGE: sntp [ -<flag> [<val>] | --<name>[@{=| @}<val>] ]... \
[ hostname-or-IP ...]
Flg Arg Option-Name Description
/*
* EDIT THIS FILE WITH CAUTION (sntp-opts.c)
*
- * It has been AutoGen-ed December 6, 2012 at 02:11:18 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 6, 2012 at 07:39:53 AM by AutoGen 5.16.2
* From the definitions sntp-opts.def
* and the template file options
*
* sntp option static const strings
*/
static char const sntp_opt_strs[2500] =
-/* 0 */ "sntp 4.2.7p331\n"
+/* 0 */ "sntp 4.2.7p332\n"
"Copyright (C) 1970-2012 The University of Delaware, all rights reserved.\n"
"This is free software. It is licensed for use, modification and\n"
"redistribution under the terms of the NTP License, copies of which\n"
/* 2244 */ "LOAD_OPTS\0"
/* 2254 */ "no-load-opts\0"
/* 2267 */ "SNTP\0"
-/* 2272 */ "sntp - standard Simple Network Time Protocol client program - Ver. 4.2.7p331\n"
+/* 2272 */ "sntp - standard Simple Network Time Protocol client program - Ver. 4.2.7p332\n"
"USAGE: %s [ -<flag> [<val>] | --<name>[{=| }<val>] ]... \\\n"
"\t\t[ hostname-or-IP ...]\n\0"
/* 2433 */ "$HOME\0"
/* 2441 */ ".ntprc\0"
/* 2448 */ "http://bugs.ntp.org, bugs@ntp.org\0"
/* 2482 */ "\n\n\0"
-/* 2485 */ "sntp 4.2.7p331";
+/* 2485 */ "sntp 4.2.7p332";
/*
* ipv4 option description with
/*
* EDIT THIS FILE WITH CAUTION (sntp-opts.h)
*
- * It has been AutoGen-ed December 6, 2012 at 02:11:18 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 6, 2012 at 07:39:52 AM by AutoGen 5.16.2
* From the definitions sntp-opts.def
* and the template file options
*
} teOptIndex;
#define OPTION_CT 23
-#define SNTP_VERSION "4.2.7p331"
-#define SNTP_FULL_VERSION "sntp 4.2.7p331"
+#define SNTP_VERSION "4.2.7p332"
+#define SNTP_FULL_VERSION "sntp 4.2.7p332"
/*
* Interface defines for all options. Replace "n" with the UPPER_CASED
-.TH sntp 1sntpman "06 Dec 2012" "4.2.7p331" "User Commands"
+.TH sntp 1sntpman "06 Dec 2012" "4.2.7p332" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (sntp-opts.man)
.\"
-.\" It has been AutoGen-ed December 6, 2012 at 02:11:59 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:45:55 AM by AutoGen 5.16.2
.\" From the definitions sntp-opts.def
.\" and the template file agman-cmd.tpl
.\"
.RB [ \-\fIflag\fP " [\fIvalue\fP]]... [" \-\-\fIopt\-name\fP " [[=| ]\fIvalue\fP]]..." [ hostname-or-IP ...]
.PP
.SH DESCRIPTION
-.B
-can be used as an SNTP client to query a NTP or SNTP server and either display
-the time or set the local system's time (given suitable privilege). It can be
-run as an interactive command or from a
-.Ic cron
-job.
-NTP (the Network Time Protocol) and SNTP (the Simple Network Time Protocol)
-are defined and described by RFC 5905.
-.PP
-The default is to write the estimated correct local date and time (i.e. not
-UTC) to the standard output in a format like:
-.Ic "'1996-10-15 20:17:25.123 (+0800) +4.567 +/- 0.089 [host] IP sN'"
-where the
-.Ic "'(+0800)'"
-means that to get to UTC from the reported local time one must
-add 8 hours and 0 minutes,
-the
-.Ic "'+4.567'"
-indicates the local clock is 4.567 seconds behind the correct time
-(so 4.567 seconds must be added to the local clock to get it to be correct).
-Note that the number of decimals printed for this value will change
-based on the reported precision of the server.
-.Ic "'+/- 0.089'"
-is the reported
-.I synchronization distance
-(in seconds), which represents the maximum error due to all causes.
-If the server does not report valid data needed to calculate the
-synchronization distance, this will be reported as
-.Ic "'+/- ?'" .
-If the
-.I host
-is different from the
-.I IP ,
-both will be displayed.
-Otherwise, only the
-.I IP
-is displayed.
-Finally, the
-.I stratum
-of the host is reported.
.SH "OPTIONS"
.TP
.BR \-4 ", " -\-ipv4
If any of these are directories, then the file \fI.ntprc\fP
is searched for within those directories.
.SH USAGE
-.TP
-.BR Li "sntp ntpserver.somewhere"
-is the simplest use of this program
-and can be run as an unprivileged command
-to check the current time and error in the local clock.
-.TP
-.BR Li "sntp -a ntpserver.somewhere"
-With suitable privilege,
-run as a command
-or from a
-.Xr cron 8
-job,
-.Ic "sntp -a"
-will reset the local clock from a synchronized specified server,
-like the (deprecated)
-.Xr ntpdate 1ntpdatemdoc ,
-or
-.Xr rdate 8
-commands.
.SH "ENVIRONMENT"
See \fBOPTION PRESETS\fP for configuration environment variables.
.SH "FILES"
libopts had an internal operational error. Please report
it to autogen-users@lists.sourceforge.net. Thank you.
.SH AUTHORS
-.An "Johannes Maximilian Kuehn"
-.An "Harlan Stenn"
-.An "Dave Hart"
.SH "COPYRIGHT"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.SH "BUGS"
Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.SH NOTES
-This document corresponds to version @VERSION@ of
-.B .
.PP
This manual page was \fIAutoGen\fP-erated from the \fBsntp\fP
option definitions.
.Dd December 6 2012
.Dt SNTP 1sntpmdoc User Commands
-.Os FreeBSD 6.4-STABLE
+.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (sntp-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 6, 2012 at 02:11:47 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:46:02 AM by AutoGen 5.16.2
.\" From the definitions sntp-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
[ hostname-or-IP ...]
.Pp
.Sh DESCRIPTION
-.Nm
-can be used as an SNTP client to query a NTP or SNTP server and either display
-the time or set the local system's time (given suitable privilege). It can be
-run as an interactive command or from a
-.Ic cron
-job.
-NTP (the Network Time Protocol) and SNTP (the Simple Network Time Protocol)
-are defined and described by RFC 5905.
-.Pp
-The default is to write the estimated correct local date and time (i.e. not
-UTC) to the standard output in a format like:
-.Ic "'1996-10-15 20:17:25.123 (+0800) +4.567 +/- 0.089 [host] IP sN'"
-where the
-.Ic "'(+0800)'"
-means that to get to UTC from the reported local time one must
-add 8 hours and 0 minutes,
-the
-.Ic "'+4.567'"
-indicates the local clock is 4.567 seconds behind the correct time
-(so 4.567 seconds must be added to the local clock to get it to be correct).
-Note that the number of decimals printed for this value will change
-based on the reported precision of the server.
-.Ic "'+/- 0.089'"
-is the reported
-.Em synchronization distance
-(in seconds), which represents the maximum error due to all causes.
-If the server does not report valid data needed to calculate the
-synchronization distance, this will be reported as
-.Ic "'+/- ?'" .
-If the
-.Em host
-is different from the
-.Em IP ,
-both will be displayed.
-Otherwise, only the
-.Em IP
-is displayed.
-Finally, the
-.Em stratum
-of the host is reported.
.Sh "OPTIONS"
.Bl -tag
.It \-4 ", " -\-ipv4
If any of these are directories, then the file \fI.ntprc\fP
is searched for within those directories.
.Sh USAGE
-.Bl -tag -width indent
-.It Li "sntp ntpserver.somewhere"
-is the simplest use of this program
-and can be run as an unprivileged command
-to check the current time and error in the local clock.
-.It Li "sntp -a ntpserver.somewhere"
-With suitable privilege,
-run as a command
-or from a
-.Xr cron 8
-job,
-.Ic "sntp -a"
-will reset the local clock from a synchronized specified server,
-like the (deprecated)
-.Xr ntpdate 1ntpdatemdoc ,
-or
-.Xr rdate 8
-commands.
-.El
.Sh "ENVIRONMENT"
See \fBOPTION PRESETS\fP for configuration environment variables.
.Sh "FILES"
it to autogen-users@lists.sourceforge.net. Thank you.
.El
.Sh AUTHORS
-.An "Johannes Maximilian Kuehn"
-.An "Harlan Stenn"
-.An "Dave Hart"
.Sh "COPYRIGHT"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.Sh "BUGS"
Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.Sh NOTES
-This document corresponds to version @VERSION@ of
-.Nm .
.Pp
This manual page was \fIAutoGen\fP-erated from the \fBsntp\fP
option definitions.
<title>Sntp User's Manual</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="Sntp User's Manual">
-<meta name="generator" content="makeinfo 4.13">
+<meta name="generator" content="makeinfo 4.7">
<link title="Top" rel="top" href="#Top">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
<meta http-equiv="Content-Style-Type" content="text/css">
pre.smallformat { font-family:inherit; font-size:smaller }
pre.smallexample { font-size:smaller }
pre.smalllisp { font-size:smaller }
- span.sc { font-variant:small-caps }
- span.roman { font-family:serif; font-weight:normal; }
- span.sansserif { font-family:sans-serif; font-weight:normal; }
+ span.sc { font-variant:small-caps }
+ span.roman { font-family: serif; font-weight: normal; }
--></style>
</head>
<body>
<h1 class="settitle">Sntp User's Manual</h1>
<div class="node">
-<a name="Top"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-Description">sntp Description</a>,
+
<a name="Top"></a>Next: <a rel="next" accesskey="n" href="#sntp-Description">sntp Description</a>,
Previous: <a rel="previous" accesskey="p" href="#dir">(dir)</a>,
Up: <a rel="up" accesskey="u" href="#dir">(dir)</a>
-
+<br>
</div>
<h2 class="unnumbered">Simple Network Time Protocol User Manual</h2>
clock. Run as root, it can correct the system clock to this offset as
well. It can be run as an interactive command or from a cron job.
- <p>This document applies to version 4.2.7p331 of <code>sntp</code>.
+ <p>This document applies to version 4.2.7p332 of <code>sntp</code>.
<p>The program implements the SNTP protocol as defined by RFC 5905, the NTPv4
IETF specification.
</ul>
<div class="node">
-<a name="sntp-Description"></a>
<p><hr>
-
-
+<a name="sntp-Description"></a>
+<br>
</div>
<!-- node-name, next, previous, up -->
error bound of the system clock relative to the server clock.
<div class="node">
-<a name="sntp-Invocation"></a>
<p><hr>
-
-
+<a name="sntp-Invocation"></a>
+<br>
</div>
<h3 class="section">Invoking sntp</h3>
This software is released under the NTP license, <http://ntp.org/license>.
<ul class="menu">
-<li><a accesskey="1" href="#sntp-usage">sntp usage</a>: sntp help/usage (<samp><span class="option">--help</span></samp>)
+<li><a accesskey="1" href="#sntp-usage">sntp usage</a>: sntp help/usage (<span class="option">--help</span>)
<li><a accesskey="2" href="#sntp-ipv4">sntp ipv4</a>: ipv4 option (-4)
<li><a accesskey="3" href="#sntp-ipv6">sntp ipv6</a>: ipv6 option (-6)
<li><a accesskey="4" href="#sntp-authentication">sntp authentication</a>: authentication option (-a)
</ul>
<div class="node">
-<a name="sntp-usage"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-ipv4">sntp ipv4</a>,
+
<a name="sntp-usage"></a>Next: <a rel="next" accesskey="n" href="#sntp-ipv4">sntp ipv4</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
-<h4 class="subsection">sntp help/usage (<samp><span class="option">--help</span></samp>)</h4>
+<h4 class="subsection">sntp help/usage (<span class="option">--help</span>)</h4>
<p><a name="index-sntp-help-3"></a>
This is the automatically generated usage text for sntp.
<p>The text printed is the same whether selected with the <code>help</code> option
-(<samp><span class="option">--help</span></samp>) or the <code>more-help</code> option (<samp><span class="option">--more-help</span></samp>). <code>more-help</code> will print
+(<span class="option">--help</span>) or the <code>more-help</code> option (<span class="option">--more-help</span>). <code>more-help</code> will print
the usage text by passing it through a pager program.
<code>more-help</code> is disabled on platforms without a working
<code>fork(2)</code> function. The <code>PAGER</code> environment variable is
-used to select the program, defaulting to <samp><span class="file">more</span></samp>. Both will exit
+used to select the program, defaulting to <span class="file">more</span>. Both will exit
with a status code of 0.
-<pre class="example">sntp - standard Simple Network Time Protocol client program - Ver. 4.2.7p331
+<pre class="example">sntp - standard Simple Network Time Protocol client program - Ver. 4.2.7p332
USAGE: sntp [ -<flag> [<val>] | --<name>[{=| }<val>] ]... \
[ hostname-or-IP ...]
Flg Arg Option-Name Description
please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
</pre>
<div class="node">
-<a name="sntp-ipv4"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-ipv6">sntp ipv6</a>,
+
<a name="sntp-ipv4"></a>Next: <a rel="next" accesskey="n" href="#sntp-ipv6">sntp ipv6</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-usage">sntp usage</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">ipv4 option (-4)</h4>
<p>Force DNS resolution of the following host names on the command line
to the IPv4 namespace.
<div class="node">
-<a name="sntp-ipv6"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-authentication">sntp authentication</a>,
+
<a name="sntp-ipv6"></a>Next: <a rel="next" accesskey="n" href="#sntp-authentication">sntp authentication</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-ipv4">sntp ipv4</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">ipv6 option (-6)</h4>
<p>Force DNS resolution of the following host names on the command line
to the IPv6 namespace.
<div class="node">
-<a name="sntp-authentication"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-broadcast">sntp broadcast</a>,
+
<a name="sntp-authentication"></a>Next: <a rel="next" accesskey="n" href="#sntp-broadcast">sntp broadcast</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-ipv6">sntp ipv6</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">authentication option (-a)</h4>
<p><a name="index-sntp_002dauthentication-6"></a>
This is the “enable authentication with the key <var>auth-keynumber</var>” option.
-This option takes an argument number <samp><span class="file">auth-keynumber</span></samp>.
+This option takes an argument number <span class="file">auth-keynumber</span>.
Enable authentication using the key specified in this option's
-argument. The argument of this option is the <samp><span class="option">keyid</span></samp>, a
-number specified in the <samp><span class="option">keyfile</span></samp> as this key's identifier.
-See the <samp><span class="option">keyfile</span></samp> option (<samp><span class="option">-k</span></samp>) for more details.
+argument. The argument of this option is the <span class="option">keyid</span>, a
+number specified in the <span class="option">keyfile</span> as this key's identifier.
+See the <span class="option">keyfile</span> option (<span class="option">-k</span>) for more details.
<div class="node">
-<a name="sntp-broadcast"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-concurrent">sntp concurrent</a>,
+
<a name="sntp-broadcast"></a>Next: <a rel="next" accesskey="n" href="#sntp-concurrent">sntp concurrent</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-authentication">sntp authentication</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">broadcast option (-b)</h4>
<p><a name="index-sntp_002dbroadcast-7"></a>
This is the “listen to the address specified for broadcast time sync” option.
-This option takes an argument string <samp><span class="file">broadcast-address</span></samp>.
+This option takes an argument string <span class="file">broadcast-address</span>.
<p class="noindent">This option has some usage constraints. It:
<ul>
<p>If specified <code>sntp</code> will listen to the specified address
for NTP broadcasts. The default maximum wait time
-can (and probably should) be modified with <samp><span class="option">-t</span></samp>.
+can (and probably should) be modified with <span class="option">-t</span>.
<div class="node">
-<a name="sntp-concurrent"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-gap">sntp gap</a>,
+
<a name="sntp-concurrent"></a>Next: <a rel="next" accesskey="n" href="#sntp-gap">sntp gap</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-broadcast">sntp broadcast</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">concurrent option (-c)</h4>
<p><a name="index-sntp_002dconcurrent-8"></a>
This is the “concurrently query all ips returned for host-name” option.
-This option takes an argument string <samp><span class="file">host-name</span></samp>.
+This option takes an argument string <span class="file">host-name</span>.
<p class="noindent">This option has some usage constraints. It:
<ul>
<code>ntpd</code>, and therefore <code>sntp</code> will send queries to these IPs
one after another, with a 2-second gap in between each query.
- <p>The <samp><span class="option">-c</span></samp> or <samp><span class="option">--concurrent</span></samp> flag says that any IPs
+ <p>The <span class="option">-c</span> or <span class="option">--concurrent</span> flag says that any IPs
returned for the DNS lookup of the supplied host-name are on
different machines, so we can send concurrent queries.
<div class="node">
-<a name="sntp-gap"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-kod">sntp kod</a>,
+
<a name="sntp-gap"></a>Next: <a rel="next" accesskey="n" href="#sntp-kod">sntp kod</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-concurrent">sntp concurrent</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">gap option (-g)</h4>
<p><a name="index-sntp_002dgap-9"></a>
This is the “the gap (in milliseconds) between time requests” option.
-This option takes an argument number <samp><span class="file">milliseconds</span></samp>.
+This option takes an argument number <span class="file">milliseconds</span>.
Since we're only going to use the first valid response we get and
there is benefit to specifying a good number of servers to query,
separate the queries we send out by the specified number of
milliseconds.
<div class="node">
-<a name="sntp-kod"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-keyfile">sntp keyfile</a>,
+
<a name="sntp-kod"></a>Next: <a rel="next" accesskey="n" href="#sntp-keyfile">sntp keyfile</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-gap">sntp gap</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">kod option (-K)</h4>
<p><a name="index-sntp_002dkod-10"></a>
This is the “kod history filename” option.
-This option takes an argument file <samp><span class="file">file-name</span></samp>.
+This option takes an argument file <span class="file">file-name</span>.
Specifies the filename to be used for the persistent history of KoD
responses received from servers.
<div class="node">
-<a name="sntp-keyfile"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-logfile">sntp logfile</a>,
+
<a name="sntp-keyfile"></a>Next: <a rel="next" accesskey="n" href="#sntp-logfile">sntp logfile</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-kod">sntp kod</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">keyfile option (-k)</h4>
<p><a name="index-sntp_002dkeyfile-11"></a>
-This is the “look in this file for the key specified with <samp><span class="option">-a</span></samp>” option.
-This option takes an argument file <samp><span class="file">file-name</span></samp>.
+This is the “look in this file for the key specified with <span class="option">-a</span>” option.
+This option takes an argument file <span class="file">file-name</span>.
This option specifies the keyfile.
-<code>sntp</code> will search for the key specified with <samp><span class="option">-a</span></samp>
-<samp><span class="file">keyno</span></samp> in this file. See <samp><span class="command">ntp.keys(5)</span></samp> for more
+<code>sntp</code> will search for the key specified with <span class="option">-a</span>
+<span class="file">keyno</span> in this file. See <span class="command">ntp.keys(5)</span> for more
information.
<div class="node">
-<a name="sntp-logfile"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-steplimit">sntp steplimit</a>,
+
<a name="sntp-logfile"></a>Next: <a rel="next" accesskey="n" href="#sntp-steplimit">sntp steplimit</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-keyfile">sntp keyfile</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">logfile option (-l)</h4>
<p><a name="index-sntp_002dlogfile-12"></a>
This is the “log to specified logfile” option.
-This option takes an argument file <samp><span class="file">file-name</span></samp>.
+This option takes an argument file <span class="file">file-name</span>.
This option causes the client to write log messages to the specified
-<samp><span class="file">logfile</span></samp>.
+<span class="file">logfile</span>.
<div class="node">
-<a name="sntp-steplimit"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-ntpversion">sntp ntpversion</a>,
+
<a name="sntp-steplimit"></a>Next: <a rel="next" accesskey="n" href="#sntp-ntpversion">sntp ntpversion</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-logfile">sntp logfile</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">steplimit option (-M)</h4>
<p><a name="index-sntp_002dsteplimit-13"></a>
This is the “adjustments less than <var>steplimit</var> msec will be slewed” option.
This option takes an argument number.
-If the time adjustment is less than <samp><span class="file">steplimit</span></samp> milliseconds,
-slew the amount using <samp><span class="command">adjtime(2)</span></samp>. Otherwise, step the
-correction using <samp><span class="command">settimeofday(2)</span></samp>.
+If the time adjustment is less than <span class="file">steplimit</span> milliseconds,
+slew the amount using <span class="command">adjtime(2)</span>. Otherwise, step the
+correction using <span class="command">settimeofday(2)</span>.
<div class="node">
-<a name="sntp-ntpversion"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-usereservedport">sntp usereservedport</a>,
+
<a name="sntp-ntpversion"></a>Next: <a rel="next" accesskey="n" href="#sntp-usereservedport">sntp usereservedport</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-steplimit">sntp steplimit</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">ntpversion option (-o)</h4>
This is the “send <var>int</var> as our ntp protocol version” option.
This option takes an argument number.
When sending requests to a remote server, tell them we are running
-NTP protocol version <samp><span class="file">ntpversion</span></samp> .
+NTP protocol version <span class="file">ntpversion</span> .
<div class="node">
-<a name="sntp-usereservedport"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-timeout">sntp timeout</a>,
+
<a name="sntp-usereservedport"></a>Next: <a rel="next" accesskey="n" href="#sntp-timeout">sntp timeout</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-ntpversion">sntp ntpversion</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">usereservedport option (-r)</h4>
Use port 123, which is reserved for NTP, for our network
communications.
<div class="node">
-<a name="sntp-timeout"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-wait">sntp wait</a>,
+
<a name="sntp-timeout"></a>Next: <a rel="next" accesskey="n" href="#sntp-wait">sntp wait</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-usereservedport">sntp usereservedport</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">timeout option (-t)</h4>
<p><a name="index-sntp_002dtimeout-16"></a>
This is the “the number of seconds to wait for responses” option.
-This option takes an argument number <samp><span class="file">seconds</span></samp>.
+This option takes an argument number <span class="file">seconds</span>.
When waiting for a reply, <code>sntp</code> will wait the number
of seconds specified before giving up. The default should be
more than enough for a unicast response. If <code>sntp</code> is
only waiting for a broadcast response a longer timeout is
likely needed.
<div class="node">
-<a name="sntp-wait"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-config">sntp config</a>,
+
<a name="sntp-wait"></a>Next: <a rel="next" accesskey="n" href="#sntp-config">sntp config</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-timeout">sntp timeout</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">wait option</h4>
<p>If we are not setting the time, wait for all pending responses.
<div class="node">
-<a name="sntp-config"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-exit-status">sntp exit status</a>,
+
<a name="sntp-config"></a>Next: <a rel="next" accesskey="n" href="#sntp-exit-status">sntp exit status</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-wait">sntp wait</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">presetting/configuring sntp</h4>
<li>$PWD
</ul>
The environment variables <code>HOME</code>, and <code>PWD</code>
-are expanded and replaced when <samp><span class="file">sntp</span></samp> runs.
+are expanded and replaced when <span class="file">sntp</span> runs.
For any of these that are plain files, they are simply processed.
-For any that are directories, then a file named <samp><span class="file">.ntprc</span></samp> is searched for
+For any that are directories, then a file named <span class="file">.ntprc</span> is searched for
within that directory and processed.
<p>Configuration files may be in a wide variety of formats.
first letter of the argument is examined:
<dl>
-<dt>‘<samp><span class="samp">version</span></samp>’<dd>Only print the version. This is the default.
-<br><dt>‘<samp><span class="samp">copyright</span></samp>’<dd>Name the copyright usage licensing terms.
-<br><dt>‘<samp><span class="samp">verbose</span></samp>’<dd>Print the full copyright usage licensing terms.
+<dt><span class="samp">version</span><dd>Only print the version. This is the default.
+<br><dt><span class="samp">copyright</span><dd>Name the copyright usage licensing terms.
+<br><dt><span class="samp">verbose</span><dd>Print the full copyright usage licensing terms.
</dl>
<div class="node">
-<a name="sntp-exit-status"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-Usage">sntp Usage</a>,
+
<a name="sntp-exit-status"></a>Next: <a rel="next" accesskey="n" href="#sntp-Usage">sntp Usage</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-config">sntp config</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">sntp exit status</h4>
<p>One of the following exit values will be returned:
<dl>
-<dt>‘<samp><span class="samp">0 (EXIT_SUCCESS)</span></samp>’<dd>Successful program execution.
-<br><dt>‘<samp><span class="samp">1 (EXIT_FAILURE)</span></samp>’<dd>The operation failed or the command syntax was not valid.
-<br><dt>‘<samp><span class="samp">66 (EX_NOINPUT)</span></samp>’<dd>A specified configuration file could not be loaded.
-<br><dt>‘<samp><span class="samp">70 (EX_SOFTWARE)</span></samp>’<dd>libopts had an internal operational error. Please report
+<dt><span class="samp">0 (EXIT_SUCCESS)</span><dd>Successful program execution.
+<br><dt><span class="samp">1 (EXIT_FAILURE)</span><dd>The operation failed or the command syntax was not valid.
+<br><dt><span class="samp">66 (EX_NOINPUT)</span><dd>A specified configuration file could not be loaded.
+<br><dt><span class="samp">70 (EX_SOFTWARE)</span><dd>libopts had an internal operational error. Please report
it to autogen-users@lists.sourceforge.net. Thank you.
</dl>
<div class="node">
-<a name="sntp-Usage"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-Authors">sntp Authors</a>,
+
<a name="sntp-Usage"></a>Next: <a rel="next" accesskey="n" href="#sntp-Authors">sntp Authors</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-exit-status">sntp exit status</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">sntp Usage</h4>
<dl>
-<dt>‘<samp><span class="samp">Li</span></samp>’<dd>is the simplest use of this program
+<dt><span class="samp">Li</span><dd>is the simplest use of this program
and can be run as an unprivileged command
to check the current time and error in the local clock.
-<br><dt>‘<samp><span class="samp">Li</span></samp>’<dd>With suitable privilege,
+<br><dt><span class="samp">Li</span><dd>With suitable privilege,
run as a command
or from a
<code>cron(8)</code>
commands.
<div class="node">
-<a name="sntp-Authors"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#sntp-Notes">sntp Notes</a>,
+
<a name="sntp-Authors"></a>Next: <a rel="next" accesskey="n" href="#sntp-Notes">sntp Notes</a>,
Previous: <a rel="previous" accesskey="p" href="#sntp-Usage">sntp Usage</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">sntp Authors</h4>
"Dave
Hart"
<div class="node">
-<a name="sntp-Notes"></a>
<p><hr>
-Previous: <a rel="previous" accesskey="p" href="#sntp-Authors">sntp Authors</a>,
+
<a name="sntp-Notes"></a>Previous: <a rel="previous" accesskey="p" href="#sntp-Authors">sntp Authors</a>,
Up: <a rel="up" accesskey="u" href="#sntp-Invocation">sntp Invocation</a>
-
+<br>
</div>
<h4 class="subsection">sntp Notes</h4>
<code>sntp</code>.
<div class="node">
-<a name="Usage"></a>
<p><hr>
-
-
+<a name="Usage"></a>
+<br>
</div>
<!-- node-name, next, previous, up -->
For example:
<pre class="example"> sntp ntpserver.somewhere
-</pre>
+ </pre>
<p>With suitable privilege, it can be run as a command or in a
<code>crom</code> job to reset the local clock from a reliable server, like
the <code>ntpdate</code> and <code>rdate</code> commands.
For example:
<pre class="example"> sntp -a ntpserver.somewhere
-</pre>
+ </pre>
</body></html>
-.TH sntp @SNTP_MS@ "06 Dec 2012" "4.2.7p331" "User Commands"
+.TH sntp @SNTP_MS@ "06 Dec 2012" "4.2.7p332" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (sntp-opts.man)
.\"
-.\" It has been AutoGen-ed December 6, 2012 at 02:11:59 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:45:55 AM by AutoGen 5.16.2
.\" From the definitions sntp-opts.def
.\" and the template file agman-cmd.tpl
.\"
.RB [ \-\fIflag\fP " [\fIvalue\fP]]... [" \-\-\fIopt\-name\fP " [[=| ]\fIvalue\fP]]..." [ hostname-or-IP ...]
.PP
.SH DESCRIPTION
-.B
-can be used as an SNTP client to query a NTP or SNTP server and either display
-the time or set the local system's time (given suitable privilege). It can be
-run as an interactive command or from a
-.Ic cron
-job.
-NTP (the Network Time Protocol) and SNTP (the Simple Network Time Protocol)
-are defined and described by RFC 5905.
-.PP
-The default is to write the estimated correct local date and time (i.e. not
-UTC) to the standard output in a format like:
-.Ic "'1996-10-15 20:17:25.123 (+0800) +4.567 +/- 0.089 [host] IP sN'"
-where the
-.Ic "'(+0800)'"
-means that to get to UTC from the reported local time one must
-add 8 hours and 0 minutes,
-the
-.Ic "'+4.567'"
-indicates the local clock is 4.567 seconds behind the correct time
-(so 4.567 seconds must be added to the local clock to get it to be correct).
-Note that the number of decimals printed for this value will change
-based on the reported precision of the server.
-.Ic "'+/- 0.089'"
-is the reported
-.I synchronization distance
-(in seconds), which represents the maximum error due to all causes.
-If the server does not report valid data needed to calculate the
-synchronization distance, this will be reported as
-.Ic "'+/- ?'" .
-If the
-.I host
-is different from the
-.I IP ,
-both will be displayed.
-Otherwise, only the
-.I IP
-is displayed.
-Finally, the
-.I stratum
-of the host is reported.
.SH "OPTIONS"
.TP
.BR \-4 ", " -\-ipv4
If any of these are directories, then the file \fI.ntprc\fP
is searched for within those directories.
.SH USAGE
-.TP
-.BR Li "sntp ntpserver.somewhere"
-is the simplest use of this program
-and can be run as an unprivileged command
-to check the current time and error in the local clock.
-.TP
-.BR Li "sntp -a ntpserver.somewhere"
-With suitable privilege,
-run as a command
-or from a
-.Xr cron 8
-job,
-.Ic "sntp -a"
-will reset the local clock from a synchronized specified server,
-like the (deprecated)
-.Xr ntpdate @NTPDATE_MS@ ,
-or
-.Xr rdate 8
-commands.
.SH "ENVIRONMENT"
See \fBOPTION PRESETS\fP for configuration environment variables.
.SH "FILES"
libopts had an internal operational error. Please report
it to autogen-users@lists.sourceforge.net. Thank you.
.SH AUTHORS
-.An "Johannes Maximilian Kuehn"
-.An "Harlan Stenn"
-.An "Dave Hart"
.SH "COPYRIGHT"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.SH "BUGS"
Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.SH NOTES
-This document corresponds to version @VERSION@ of
-.B .
.PP
This manual page was \fIAutoGen\fP-erated from the \fBsntp\fP
option definitions.
.Dd December 6 2012
.Dt SNTP @SNTP_MS@ User Commands
-.Os FreeBSD 6.4-STABLE
+.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (sntp-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 6, 2012 at 02:11:47 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:46:02 AM by AutoGen 5.16.2
.\" From the definitions sntp-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
[ hostname-or-IP ...]
.Pp
.Sh DESCRIPTION
-.Nm
-can be used as an SNTP client to query a NTP or SNTP server and either display
-the time or set the local system's time (given suitable privilege). It can be
-run as an interactive command or from a
-.Ic cron
-job.
-NTP (the Network Time Protocol) and SNTP (the Simple Network Time Protocol)
-are defined and described by RFC 5905.
-.Pp
-The default is to write the estimated correct local date and time (i.e. not
-UTC) to the standard output in a format like:
-.Ic "'1996-10-15 20:17:25.123 (+0800) +4.567 +/- 0.089 [host] IP sN'"
-where the
-.Ic "'(+0800)'"
-means that to get to UTC from the reported local time one must
-add 8 hours and 0 minutes,
-the
-.Ic "'+4.567'"
-indicates the local clock is 4.567 seconds behind the correct time
-(so 4.567 seconds must be added to the local clock to get it to be correct).
-Note that the number of decimals printed for this value will change
-based on the reported precision of the server.
-.Ic "'+/- 0.089'"
-is the reported
-.Em synchronization distance
-(in seconds), which represents the maximum error due to all causes.
-If the server does not report valid data needed to calculate the
-synchronization distance, this will be reported as
-.Ic "'+/- ?'" .
-If the
-.Em host
-is different from the
-.Em IP ,
-both will be displayed.
-Otherwise, only the
-.Em IP
-is displayed.
-Finally, the
-.Em stratum
-of the host is reported.
.Sh "OPTIONS"
.Bl -tag
.It \-4 ", " -\-ipv4
If any of these are directories, then the file \fI.ntprc\fP
is searched for within those directories.
.Sh USAGE
-.Bl -tag -width indent
-.It Li "sntp ntpserver.somewhere"
-is the simplest use of this program
-and can be run as an unprivileged command
-to check the current time and error in the local clock.
-.It Li "sntp -a ntpserver.somewhere"
-With suitable privilege,
-run as a command
-or from a
-.Xr cron 8
-job,
-.Ic "sntp -a"
-will reset the local clock from a synchronized specified server,
-like the (deprecated)
-.Xr ntpdate @NTPDATE_MS@ ,
-or
-.Xr rdate 8
-commands.
-.El
.Sh "ENVIRONMENT"
See \fBOPTION PRESETS\fP for configuration environment variables.
.Sh "FILES"
it to autogen-users@lists.sourceforge.net. Thank you.
.El
.Sh AUTHORS
-.An "Johannes Maximilian Kuehn"
-.An "Harlan Stenn"
-.An "Dave Hart"
.Sh "COPYRIGHT"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.Sh "BUGS"
Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.Sh NOTES
-This document corresponds to version @VERSION@ of
-.Nm .
.Pp
This manual page was \fIAutoGen\fP-erated from the \fBsntp\fP
option definitions.
#
# EDIT THIS FILE WITH CAUTION (invoke-ntp-keygen.texi)
#
-# It has been AutoGen-ed December 3, 2012 at 11:42:50 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 6, 2012 at 07:45:38 AM by AutoGen 5.16.2
# From the definitions ntp-keygen-opts.def
# and the template file agtexi-cmd.tpl
@end ignore
@exampleindent 0
@example
-ntp-keygen (ntp) - Create a NTP host key - Ver. 4.2.7p331
+ntp-keygen (ntp) - Create a NTP host key - Ver. 4.2.7p332
USAGE: ntp-keygen [ -<flag> [<val>] | --<name>[@{=| @}<val>] ]...
Flg Arg Option-Name Description
-b Num imbits identity modulus bits
/*
* EDIT THIS FILE WITH CAUTION (ntp-keygen-opts.c)
*
- * It has been AutoGen-ed December 3, 2012 at 11:42:35 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 6, 2012 at 07:45:25 AM by AutoGen 5.16.2
* From the definitions ntp-keygen-opts.def
* and the template file options
*
* ntp-keygen option static const strings
*/
static char const ntp_keygen_opt_strs[2358] =
-/* 0 */ "ntp-keygen (ntp) 4.2.7p331\n"
+/* 0 */ "ntp-keygen (ntp) 4.2.7p332\n"
"Copyright (C) 1970-2012 The University of Delaware, all rights reserved.\n"
"This is free software. It is licensed for use, modification and\n"
"redistribution under the terms of the NTP License, copies of which\n"
/* 2136 */ "no-load-opts\0"
/* 2149 */ "no\0"
/* 2152 */ "NTP_KEYGEN\0"
-/* 2163 */ "ntp-keygen (ntp) - Create a NTP host key - Ver. 4.2.7p331\n"
+/* 2163 */ "ntp-keygen (ntp) - Create a NTP host key - Ver. 4.2.7p332\n"
"USAGE: %s [ -<flag> [<val>] | --<name>[{=| }<val>] ]...\n\0"
/* 2279 */ "$HOME\0"
/* 2285 */ ".\0"
/* 2287 */ ".ntprc\0"
/* 2294 */ "http://bugs.ntp.org, bugs@ntp.org\0"
/* 2328 */ "\n\n\0"
-/* 2331 */ "ntp-keygen (ntp) 4.2.7p331";
+/* 2331 */ "ntp-keygen (ntp) 4.2.7p332";
/*
* imbits option description:
/*
* EDIT THIS FILE WITH CAUTION (ntp-keygen-opts.h)
*
- * It has been AutoGen-ed December 3, 2012 at 11:42:35 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 6, 2012 at 07:45:24 AM by AutoGen 5.16.2
* From the definitions ntp-keygen-opts.def
* and the template file options
*
} teOptIndex;
#define OPTION_CT 26
-#define NTP_KEYGEN_VERSION "4.2.7p331"
-#define NTP_KEYGEN_FULL_VERSION "ntp-keygen (ntp) 4.2.7p331"
+#define NTP_KEYGEN_VERSION "4.2.7p332"
+#define NTP_KEYGEN_FULL_VERSION "ntp-keygen (ntp) 4.2.7p332"
/*
* Interface defines for all options. Replace "n" with the UPPER_CASED
-.TH ntp-keygen 1ntp-keygenman "03 Dec 2012" "ntp (4.2.7p331)" "User Commands"
+.TH ntp-keygen 1ntp-keygenman "06 Dec 2012" "ntp (4.2.7p332)" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp-keygen-opts.man)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:42:45 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:45:33 AM by AutoGen 5.16.2
.\" From the definitions ntp-keygen-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 3 2012
+.Dd December 6 2012
.Dt NTP_KEYGEN 1ntp-keygenmdoc User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp-keygen-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:42:52 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:45:40 AM by AutoGen 5.16.2
.\" From the definitions ntp-keygen-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
-.TH ntp-keygen @NTP_KEYGEN_MS@ "03 Dec 2012" "ntp (4.2.7p331)" "User Commands"
+.TH ntp-keygen @NTP_KEYGEN_MS@ "06 Dec 2012" "ntp (4.2.7p332)" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp-keygen-opts.man)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:42:45 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:45:33 AM by AutoGen 5.16.2
.\" From the definitions ntp-keygen-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 3 2012
+.Dd December 6 2012
.Dt NTP_KEYGEN @NTP_KEYGEN_MS@ User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp-keygen-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 3, 2012 at 11:42:52 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 6, 2012 at 07:45:40 AM by AutoGen 5.16.2
.\" From the definitions ntp-keygen-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
projects / thirdparty / ntp.git / commitdiff
