上QQ阅读APP看书，第一时间看更新

How it works...

NTP works in a client-server fashion, in which the client device (centos1, in our case) asks the server device (centos2) for an accurate time reading, which it then applies to the local machine.

When we wanted to make our own server, it was relatively trivial. On the server side, we only needed the line stipulating which clients could sync with centos2:

allow 192.168.33.0/24

On the client side, we needed to first remove the servers it was talking to (using sed to comment out the default pool lines), and then we added our new source-of-time as our configured server by using the following configuration lines:

server 192.168.33.11 iburst
allow 192.168.33.11

The server option is the address (or DNS name, if configured) of our source-of-truth. The iburst option simply makes the first few requests faster so that the sync can happen quicker after starting.

If we start tcpdump running on centos2, after it's been configured as a server, and then restart chronyd on centos1, we should see traffic flowing:

$ sudo tcpdump port 123 -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:35:51.370634 IP 192.168.33.10.44912 > centos2.ntp: NTPv4, Client, length 48
11:35:51.370965 IP centos2.ntp > 192.168.33.10.44912: NTPv4, Server, length 48
11:35:53.394843 IP 192.168.33.10.52976 > centos2.ntp: NTPv4, Client, length 48
11:35:53.395162 IP centos2.ntp > 192.168.33.10.52976: NTPv4, Server, length 48
11:35:55.414496 IP 192.168.33.10.42977 > centos2.ntp: NTPv4, Client, length 48
11:35:55.414659 IP centos2.ntp > 192.168.33.10.42977: NTPv4, Server, length 48
11:35:57.437187 IP 192.168.33.10.45651 > centos2.ntp: NTPv4, Client, length 48
11:35:57.437539 IP centos2.ntp > 192.168.33.10.45651: NTPv4, Server, length 48

We can see our client machine (.10) requesting time from centos2, and then centos2 responding on the next line.

This also works to highlight the iburst option in action. Note the two-second differences between packet communication.

If we now take another look at chronyc tracking on the client, we should see normal details:

$ chronyc tracking
Reference ID    : C0A8210B (192.168.33.11)
Stratum         : 3
Ref time (UTC)  : Sun Aug 19 11:37:01 2018
System time     : 0.000000264 seconds fast of NTP time
Last offset     : -0.000468330 seconds
RMS offset      : 0.000468330 seconds
Frequency       : 6.604 ppm slow
Residual freq   : -5.715 ppm
Skew            : 7.044 ppm
Root delay      : 0.016203152 seconds
Root dispersion : 0.000595987 seconds
Update interval : 64.2 seconds
Leap status     : Normal

The preceding code may take a second to populate. If you're particularly quick off the mark, try again in a few seconds.

You can again use the chronyc sources command to check that the client is talking to the right server:

$ sudo chronyc sources
210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^* 192.168.33.11                 2   6   377    48    +53us[ +106us] +/- 7783us