Specify debugging mode. This flag may occur multiple times, with each occurrence indicating greater detail of display. Blank lines are ignored. Configuration commands consist of an initial keyword followed by a list of arguments, separated by whitespace. Some arguments may be optional. These commands may not be continued over multiple lines. Arguments may be host names, host addresses written in dotted-decimal, integers, floating point numbers when specifying times in seconds and text strings.
The first three commands specify various time servers to be used and time services to be provided. In this mode, the local server can be synchronized to the remote server. In addition, the remote server can be synchronized by the local server. This is useful in a network of servers where, depending on various failure scenarios, either the local or remote server host may be the better source of time.
The peer command, and the server and broadcast commands that follow, can take the following arguments: key Indicates that all packets sent to the address are to include authentication fields, encrypted using the specified key number. The range of this number is that of an unsigned 32 bit integer. By default, an encryption field is not included. Specifies the version number to be used for outgoing NTP packets. Versions 1, 2, and 3 are the choices; version 3 is the default.
Marks the host as a preferred host. This host will be preferred for synchronization over other comparable hosts. Specifies that the local server is to operate in "client" mode with the remote server named in the command. In this mode the local server can be synchronized to the remote server, but the remote server can never be synchronized to the local server.
Ordinarily, this specification applies only to the local server operating as a transmitter. For operation as a broadcast client, see broadcastclient or multicastclient commands elsewhere in this document. The IANA has assigned the network, This is presently the only network that should be used.
The following option is used only with the broadcast mode: ttl Specifies the time-to-live TTL to use on multicast packets. Selection of the proper value, which defaults to , is something of a black art and must be coordinated with the network administrator s. Directs the local server to listen for broadcast messages on the local network, in order to discover other servers on the same subnet.
Then the server enters the "broadcastclient" mode, in which it listens for and synchronizes to succeeding broadcast messages. In order to avoid accidental or malicious disruption in this mode, both the local and remote servers must operate using authentication, with the same trusted key and key identifier.
Support for this command requires the use of authentication. If one or more IP addresses are given, the server joins the respective multicast group s. Specifies the name of the file used to record the frequency offset of the local clock oscillator.
If the file exists, it is read at startup in order to set the initial frequency offset. Then the file is updated once per hour with the current offset computed by the daemon. If the file does not exist or this command is not given, the initial frequency offset is assumed to be zero. In this case, it may take some hours for the frequency to stabilize and the residual timing errors to subside.
The file contains a single floating point value equal to the offset in parts-per-million ppm. The file is updated by first writing the current drift value into a temporary file and then using rename 2 to replace the old version. This implies that xntpd must have write permission for the directory the drift file is located in, and that file system links, symbolic or otherwise, should probably be avoided.
Provides a way to enable or disable various server options. To do so, execute a two word command, where the first word is enable or disable and the second is the flag. Flags not mentioned are unaffected. Flags that can be changed are described below, along with their default values.
Specifies the name of a file which contains the encryption keys and key identifiers used by xntpd when operating in authenticated mode. The format of this file is described later in this document. The authentication procedures require that both the local and remote servers share the same key and key identifier, defined to be used for this purpose. However, different keys can be used with different servers. The arguments are 32 bit unsigned integers.
Note, however, that key 0 is fixed and globally known. If meaningful authentication is to be performed, the 0 key should not be trusted. Specifies the key identifier to use with the ntpq 1M program, which is useful to diagnose and repair problems that affect xntpd operation. The operation of the ntpq program and xntpd conform to those specified in RFC Requests from a remote ntpq program which affect the state of the local server must be authenticated.
This requires that both the remote program and local server share a common key and key identifier. The argument to this command is a 32 bit unsigned integer. If no controlkey command is included in the configuration file, or if the keys don't match. These requests are ignored.
The list is sorted by IP address and mask, and the list is searched in this order for matches, with the last match found defining the restriction flags associated with the incoming packets. The source address of incoming packets is used for the match, with the 32 bit address being logically and'ed with the mask associated with the restriction entry and then compared with the entry's address which has also been and'ed with the mask to look for a match.
The "mask" argument defaults to A default entry address 0. Note that, while "address" is normally given in dotted-quad format, the text string "default", with no mask option, may be used to indicate the default entry.
In the current implementation, flags always restrict access, i. The flags are not orthogonal, in that more restrictive flags 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: ignore Ignore all packets from hosts which match this entry.
If this flag is specified neither queries nor time server polls will be responded to. Ignore all NTP mode 7 packets i. Time service is not affected. Ignore all NTP mode 7 packets which attempt to modify the state of the server i. Queries which return information are permitted.
Decline to provide mode 6 control message trap service to matching hosts. The trap service is a subsystem of the mode 6 control message protocol which is intended for use by remote event logging programs. 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. Ignore NTP packets whose mode is other than 7. In effect, time service is denied, though queries may still be permitted. Provide stateless time service to polling hosts, but do not allocate peer memory resources to these hosts even if they otherwise might be considered useful as future synchronization partners.
These hosts are subject to a limitation on number of clients from the same net that will be accepted. Requests from other clients from the same net are rejected. Only time request packets are taken into account.
A history of clients is kept using the monitoring capability of xntpd. Thus, monitoring is active as long as there is a restriction entry with the limited flag. Currently both variables are not runtime configurable. 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 Both ntpport and non-ntpport may be specified.
Ordinarily, xntpd reads the ntp. It is also possible to specify a working, although limited, configuration entirely on the command line, obviating the need for a configuration file. This may be particularly appropriate when the local host is to be configured as a broadcast or multicast client, with all peers being determined by listening to broadcasts at run time.
Various internal xntpd variables can be displayed and configuration options altered while the daemon is running using the ntpq and xntpdc utility programs. Specify debugging mode. This flag may occur multiple times, with each occurrence indicating greater detail of display.
This is used only if the delay cannot be computed automatically by the protocol. The xntpd configuration file is read at initial startup in order to specify the synchronization sources, modes and other related information. I am wondering where can I find those log files, thanks! NTP doesn't normally generate many log messages nor have its own log file. Presence of statistics files are controlled by the filegen options in your ntp. Sign up to join this community.
The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Learn more. Where can I look up for the ntpd log? Ask Question. Asked 10 years, 11 months ago. Active 10 years, 11 months ago. Viewed 93k times.
Improve this question.
0コメント