Chapter 32. Achieving some settings previously supported by NTP in chrony
Some settings that were in previous major version of Red Hat Enterprise Linux supported by ntp, are not supported by chrony. The following sections list such settings, and describe ways to achieve them on a system with chrony.
32.1. Monitoring by ntpq and ntpdc
chronyd cannot be monitored by the ntpq and ntpdc utilities from the ntp distribution, because chrony does not support the
NTP modes 6 and 7. It supports a different protocol and chronyc is the client implementation. For more information, see the
chronyc(1) man page.
To monitor the status of the system clock sychronized by
chronyd, you can:
- Use the tracking command
Use the ntpstat utility, which supports chrony and provides a similar output as it used to with
Example 32.1. Using the tracking command
$ chronyc -n tracking Reference ID : 0A051B0A (10.5.27.10) Stratum : 2 Ref time (UTC) : Thu Mar 08 15:46:20 2018 System time : 0.000000338 seconds slow of NTP time Last offset : +0.000339408 seconds RMS offset : 0.000339408 seconds Frequency : 2.968 ppm slow Residual freq : +0.001 ppm Skew : 3.336 ppm Root delay : 0.157559142 seconds Root dispersion : 0.001339232 seconds Update interval : 64.5 seconds Leap status : Normal
Example 32.2. Using the ntpstat utility
$ ntpstat synchronised to NTP server (10.5.27.10) at stratum 2 time correct to within 80 ms polling server every 64 s
32.2. Using authentication mechanism based on public key cryptography
In Red Hat Enterprise Linux 7, ntp supported Autokey, which is an authentication mechanism based on public key cryptography. Autokey is not supported in
On a Red Hat Enterprise Linux 8 system, it is recommended to use symmetric keys instead. Generate the keys with the
chronyc keygen command. A client and server need to share a key specified in
/etc/chrony.keys. The client can enable authentication using the
key option in the
32.3. Using ephemeral symmetric associations
In Red Hat Enterprise Linux 7,
ntpd supported ephemeral symmetric associations, which can be mobilized by packets from peers which are not specified in the
ntp.conf configuration file. In Red Hat Enterprise Linux 8,
chronyd needs all peers to be specified in
chrony.conf. Ephemeral symmetric associations are not supported.
Note that using the client/server mode enabled by the
pool directive is more secure compared to the symmetric mode enabled by the
32.4. multicast/broadcast client
Red Hat Enterprise Linux 7 supported the broadcast/multicast
NTP mode, which simplifies configuration of clients. With this mode, clients can be configured to just listen for packets sent to a multicast/broadcast address instead of listening for specific names or addresses of individual servers, which may change over time.
In Red Hat Enterprise Linux 8,
chronyd does not support the broadcast/multicast mode. The main reason is that it is less accurate and less secure than the ordinary client/server and symmetric modes.
There are several options of migration from an
NTP broadcast/multicast setup:
Configure DNS to translate a single name, such as ntp.example.com, to multiple addresses of different servers
Clients can have a static configuration using only a single pool directive to synchronize with multiple servers. If a server from the pool becomes unreacheable, or otherwise unsuitable for synchronization, the clients automatically replace it with another server from the pool.
Distribute the list of
NTPservers over DHCP
When NetworkManager gets a list of
NTPservers from the DHCP server,
chronydis automatically configured to use them. This feature can be disabled by adding
Precision Time Protocol (PTP)
This option is suitable mainly for environments where servers change frequently, or if a larger group of clients needs to be able to synchronize to each other without having a designated server.
PTPwas designed for multicast messaging and works similarly to the
NTPbroadcast mode. A
PTPimplementation is available in the
PTPnormally requires hardware timestamping and support in network switches to perform well. However,
PTPis expected to work better than
NTPin the broadcast mode even with software timestamping and no support in network switches.
In networks with very large number of
PTPslaves in one communication path, it is recommended to configure the
PTPslaves with the
hybrid_e2eoption in order to reduce the amount of network traffic generated by the slaves. You can configure a computer running
NTPclient, and possibly
NTPserver, to operate also as a
PTPgrandmaster to distribute synchronized time to a large number of computers using multicast messaging.