|
|
| |
NTPD.CONF(5) |
FreeBSD File Formats Manual |
NTPD.CONF(5) |
ntpd.conf —
Network Time Protocol daemon configuration file
This manual page describes the format of the
ntpd(8)
configuration file.
ntpd.conf has the following format:
Empty lines and lines beginning with the ‘#’
character are ignored.
Keywords may be specified multiple times within the configuration
file. The basic configuration options are as follows:
listen
on address [rtable
table-id]
- ntpd(8)
has the ability to sync the local clock to remote NTP servers and, if this
directive is specified, can act as NTP server itself, redistributing the
local clock.
Specify a local IP address or a hostname the
ntpd(8)
daemon should listen on to enable remote clients synchronization. If it
appears multiple times,
ntpd(8)
will listen on each given address. If ‘*’ is given as an
address,
ntpd(8)
will listen on all local addresses using the specified routing table.
ntpd(8)
does not listen on any address by default. The optional
rtable keyword will specify which routing table
to listen on, if the operating system supports rdomains. By default
ntpd(8)
will listen using the current routing table. For example:
or
listen on 127.0.0.1
listen on ::1
listen on 127.0.0.1 rtable 4
query
from sourceaddr
- Specify a local IP address the
ntpd(8)
daemon should use for outgoing queries to subsequently specified servers,
which is useful on machines with multiple interfaces. For example:
query from 192.0.2.1
query from 2001:db8::1
sensor
device [correction
microseconds] [refid
ID-string] [stratum
stratum-value] [trusted ]
[weight weight-value]
- Specify a timedelta sensor device
ntpd(8)
should use, if the operating system supports sensors. The sensor can be
specified multiple times:
ntpd(8)
will use each given sensor that actually exists. Non-existent sensors are
ignored. If ‘*’ is given as device name,
ntpd(8)
will use all timedelta sensors it finds.
ntpd(8)
does not use any timedelta sensor by default. For example:
A correction in microseconds can be
given to compensate for the sensor's offset. The maximum correction is
127 seconds. For example, if a DCF77 receiver is lagging 70ms behind
actual time:
sensor udcf0 correction 70000
A refid
ID-string of up up to 4 ASCII characters can be
given to publish the sensor type to clients. RFC 2030 suggests some
common reference identifiers, but new identifiers "can be contrived
as appropriate." If an ID-string is not
given,
ntpd(8)
will use a generic reference ID. For example:
The stratum keyword can be used to
change the stratum value from the default of 1.
The trusted keyword indicates the time
learned is secure, trustworthy, and not vulnerable to man-in-the-middle
attacks, so constraints validation is skipped.
This is useful for boot-time correction in environments where
constraints cannot be used.
The weight keyword permits finer
control over the relative importance of time sources (servers or sensor
devices). Weights are specified in the range 1 to 10; if no weight is
given, the default is 1. A server with a weight of 5, for example, will
have five times more influence on time offset calculation than a server
with a weight of 1.
server
address [trusted ]
[weight weight-value]
- Specify the IP address or the hostname of an NTP server to synchronize to.
If it appears multiple times,
ntpd(8)
will try to synchronize to all of the servers specified. If a hostname
resolves to multiple IPv4 and/or IPv6 addresses,
ntpd(8)
uses the first address. If it does not get a reply,
ntpd(8)
retries with the next address and continues to do so until a working
address is found. For example:
server 10.0.0.2 weight 5
server ntp.example.org weight 1
To provide redundancy, it is good practice to configure
multiple servers. In general, best accuracy is obtained by using servers
that have a low network latency.
servers
address [trusted ]
[weight weight-value]
- As with
server , specify the IP address or hostname
of an NTP server to synchronize to. If it appears multiple times,
ntpd(8)
will try to synchronize to all of the servers specified. Should the
hostname resolve to multiple IP addresses,
ntpd(8)
will try to synchronize to all of them. For example:
servers pool.ntp.org
servers pool.ntp.org weight 5
ntpd(8) can
be configured to query the ‘Date’ from trusted HTTPS servers via
TLS. This time information is not used for precision but acts as an
authenticated constraint, thereby reducing the impact of unauthenticated NTP
man-in-the-middle attacks. Received NTP packets with time information falling
outside of a range near the constraint will be discarded and such NTP servers
will be marked as invalid.
Support for constraints is only available if
ntpd(8)
has been linked with libtls from LibreSSL. Configuring a constraint without
libtls causes
ntpd(8)
to log a warning message on startup.
constraint
from url [ip...]
- Specify the URL, IP address or the hostname of an HTTPS server to provide
a constraint. If the url is followed by one or more addresses the url and
addresses will be tried until a working one is found. The url path and
expected certificate name is always taken from the url specified. If
constraint from is used more than once,
ntpd(8)
will calculate a median constraint from all the servers specified.
server ntp.example.org
constraint from www.example.com
constraint from "https://9.9.9.9" "2620:fe::9"
constraints
from url
- As with
constraint from , specify the URL, IP
address or the hostname of an HTTPS server to provide a constraint. Should
the hostname resolve to multiple IP addresses,
ntpd(8)
will calculate a median constraint from all of them. For example:
servers pool.ntp.org
constraints from "https://www.google.com/"
- /usr/local/etc/ntpd.conf
- Default
ntpd(8)
configuration file.
The ntpd.conf file format first appeared in
OpenBSD 3.6.
Visit the GSP FreeBSD Man Page Interface. Output converted with ManDoc. |