Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.sai.msu.su/~er/xntp/xntpd.html
Дата изменения: Unknown Дата индексирования: Sat Dec 22 01:42:52 2007 Кодировка: Поисковые слова: р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п |
xntpd
- Network Time Protocol (NTP) daemon
xntpd [ -abdm ] [ -c conffile ] [ -e authdelay ]
[ -f driftfile ] [ -k keyfile ] [ -l logfile ] [ -p
pidfile ] [ -r broadcastdelay ] [ -s statsdir ] [ -
t key ] [ -v variable ] [ -V variable ]
xntpd
is an operating system daemon which sets and
maintains the system time-of-day in synchronism with Internet standard
time servers. xntpd
is a complete implementation of the
Network Time Protocol (NTP) version 3, as defined by RFC-1305, but also
retains compatibility with version 1 and 2 servers as defined by RFC-
1059 and RFC-1119, respectively. xntpd
does all
computations in 64-bit fixed point arithmetic and requires no floating
point support. While the ultimate precision of this design, about 232
picoseconds, is not achievable with ordinary workstations and networks
of today, it may be required with future nanosecond CPU clocks and
gigabit LANs.
The daemon can operate in any of several modes, including symmetric active/passive, client/server and broadcast/multicast, as described in RFC-1305. A broadcast/multicast client can discover remote servers, compute server-client propagation delay correction factors and configure itself automatically. This makes it possible to deploy a fleet of workstations without specifying configuration details specific to the local environment.
Ordinarily, xntpd
reads the Config.local
configuration file at startup time in order to determine the
synchronization sources and operating modes. 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.
-a
-b
-c conffile
-d
-e authdelay
-f driftfile
-k keyfile
-l logfile
-m
-p pidfile
-r broadcastdelay
-s statsdir
-t key
-v variable
-V variable
The xntpd
configuration file is read at initial startup
in order to specify the synchronization sources, modes and other related
information. Usually, it is installed in the /etc/ntp.conf
directory, but could be installed elsewhere (see the -c
conffile
command line option). The file format is similar
to other Unix configuration files - comments begin with a #
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. Optional arguments are delimited by [ ]
in the
following descriptions, while alternatives are separated by
|
. The notation [ ... ] means an optional, indefinite
repetition of the last item before the [ ... ].
See the following pages for configuration and control options. While
there is a rich set of options available, the only required option is
one or more server, peer
or broadcast
commands
described in the Configuration Options page. The
Notes on Configuring NTP and Setting up a NTP Subnet page contains
an extended discussion of these options.
Configuration Options
Authentication Options
Monitoring Options
Access Control Options
Reference Clock Options
Miscellaneous Options
/etc/ntp.conf
- the default name of the configuration
file
/etc/ntp.drift
- the default name of the drift file
/etc/ntp.keys
- the default name of the key file
xntpd
has gotten rather fat. While not huge, it has gotten
larger than might be desireable for an elevated-priority daemon running
on a workstation, particularly since many of the fancy features which
consume the space were designed more with a busy primary server, rather
than a high stratum workstation, in mind.