| Now we'll start to configure our machines. We'll do this by connecting to a public time server on the Internet first, then follow this by building our own NTP server, which the remaining clients can synchronize with. Doing it in this order will enable us to quickly get all the machines working as NTP clients, while allowing us to build a local master server in our own time. We'll use hydrogen as the client example here, although each system will require the same configuration details to be installed. First, let's check that the NTP packages have been installed. Running pkginfo should show us something similar to that shown below: hydrogen# pkginfo | grep -i ntp system SUNWntpr NTP, (Root) system SUNWntpu NTP, (Usr) hydrogen# We'll also check that we have a port defined for NTP in the services filethis will normally be set to 123: hydrogen# grep ntp /etc/services ntp 123/tcp # Network Time Protocol ntp 123/udp # Network Time Protocol hydrogen# Kernel System Variables Versions of Solaris prior to 2.6 will require a system variable named "dosynctodr" to be set to 0 to avoid conflicts between the hardware and software clocks. This is carried out by adding an entry into the system file: hydrogen# grep dosynctodr /etc/system set dosynctodr=0 hydrogen# However, if the machine is using Solaris 2.6 or above, the default is to ensure that the two clocks are synchronized, so this value must not be set. Build the Clients We've already mentioned that NTP actually prefers to be configured with a number of servers. Since we have quite a lot of public time servers available, we'll select three of them. We have chosen the two listed below, for no other reason than they are reasonably close (at least to us!), along with ntp2a.mcc.ac.uk, which we listed earlier in the section "Public Time Servers" on page 467. salmon.maths.tcd.ie (134.226.81.11) Location: Trinity College, Dublin, Ireland Synchronization: NTP secondary (stratum 2), MIPS Magnum Service Area: Ireland, UK Access Policy: open access Contact: time@maths.tcd.ie Note: salmon.maths.tcd.ie (134.226.81.11), ashe.cs.tcd.ie (134.226.32.17), and lib1.tcd.ie (134.226.1.24) peer together over local area net, and one or more usually run at stratum 2. It is normally sufficient just to pick one machine to peer with. ntp.cs.strath.ac.uk (130.159.196.123, 130.159.196.125) Location: Dept. Computer Science, Strathclyde University, Glasgow, Scotland Geographic Coordinates: 04:14W, 55:52N Synchronization: NTP V3 secondary Sun/UNIX Service Area: UK/Europe/any Access Policy: open access Contact: Ian Gordon (ntp@cs.strath.ac.uk) Note: IP addresses are subject to change; please use DNS. All three systems specify that they are "open access," which means we can simply use them when we're ready. Before we do that, it's a good idea to test that we are happy with the accuracy they will providewe do this by querying them. For example, we can use ntpq to check the Strathclyde University Server (ntp.cs.strath.ac.uk), and see which peers it knows about and what their current status is. This may show results similar to the following: hydrogen# ntpq -p ntp.cs.strath.ac.uk remote refid st t when poll reach delay offset disp ============================================================================ +fleming.cs.stra harris.cc.strat 3 u 19 128 363 0.82 0.536 251.30 -canon.inria.fr .GPS. 1 u 43 1024 377 52.51 5.567 0.76 -faui45.informat .DCFp. 1 u 442 1024 377 75.65 11.674 2.21 -Time1.Stupi.SE .PPS. 1 u 245 512 377 65.95 5.646 1.85 +ntp0.cs.strath. harris.cc.strat 3 u 43 128 352 0.92 0.506 0.46 +rockall.cc.stra ntp0.ja.net 2 u 9 128 377 2.76 -0.805 0.05 *harris.cc.strat ntp1.ja.net 2 u 121 128 377 2.01 0.541 0.08 ntp1.belbone.be 0.0.0.0 16 u 36 1024 0 0.00 0.000 16000.0 ntp2.belbone.be 0.0.0.0 16 - - 1024 0 0.00 0.000 16000.0 +130.159.62.11 ntp1.ja.net 2 u 79 128 377 4.04 1.399 0.66 hydrogen# Ntpq uses the first character to display the synchronization statusthe current server is indicated with a "*." This example shows it is currently using the server named harris.cc.strat, which is a stratum-2 server. The delay, offset, and dispersion values are all very small, so we can be quite confident in synchronizing to this system. If we wished, we could also carry out similar tests on the other machines. To save space here, we'll assume that they are OK. Now that we know which servers we would like to use, we need to configure NTP accordingly. This is quite easy as there is only one configuration file for both servers and clients, which is named /etc/inet/ntp.conf. The one we have created for hydrogen is shown below: hydrogen# cat /etc/inet/ntp.conf # # Server config for Internet NTP clients # server ntp2a.mcc.ac.uk server ntp.cs.strath.ac.uk server salmon.maths.tcd.ie driftfile /var/ntp/ntp.drift hydrogen# Let's work through the entries to see what they all refer to. First, we specified the servers, which in our case are the three public time servers mentioned earlier. Next, we specified the path name of a file known as the "drift file." This allows NTP to store the frequency error it has calculated for the clock. If this file exists, NTP will read the value when it starts and adjust the clock accordingly. This means the time will be accurate immediately, and we won't have to wait for it to smooth out over a number of hours. NTP will create the file if it doesn't exist and update it every hourwe just need to make sure it can write into the directory. Once /etc/inet/ntp.conf has been created, we can either start the NTP daemon manually by running the start-up script provided by the system, or wait for the next reboot and let the system start it automatically. We'll do it manually here: hydrogen# /etc/init.d/xntpd start hydrogen# That's the entire configuration! We just need to check that NTP is working correctly before we move on and copy the configuration file around the remaining clients. Checking the Clients As the first check, let's run ntpq to display a list of all the servers that this system can see ("-n" simply returns the server names as IP addresses rather than the names of the hosts/clocks). This shows that we are currently synchronized with 130.88.202.49, which is set to stratum 2: hydrogen# ntpq -np remote refid st t when poll reach delay offset disp =========================================================================== *130.88.202.49 194.81.227.227 2 u 57 64 77 16.94 2.481 3.22 +130.159.196.118 130.159.248.11 3 u 57 64 77 23.65 3.875 2.73 +134.226.81.11 134.226.81.3 2 u 57 64 77 122.02 -42.051 6.58 hydrogen# The "poll" column indicates how often the server will be queried, with "when" showing the countdown to the next poll. Whenever a poll is successful, a "reachability" register is updated and its value displayed in the "reach" column as an octal value. NTP uses the last eight polls in its calculations and displays the results as follows: When the NTP daemon is started, the register is cleared out and set to 0; since it is only interested in the last eight polls, this will effectively be 00000000. At the next poll, if the server returns OK, a "1" will be entered from the right-hand side to give us 00000001. If we follow this pattern and, for example, see the next four polls, lose the one after, and see the remaining two, we would end up with a value of 11111011 in binary, or 373 in octal. The correct value for the full eight polls will be 377 (binary 11111111). We can see that in our output we have "reach" set to octal 77, which is equivalent to 00111111 in binary. This indicates that we have seen the last six polls and, in our case, since we have recently started the daemon, probably means it hasn't yet completed its eight polls. Now we'll use ntptrace to show the chain of servers back to the primary time source: hydrogen# ntptrace localhost: stratum 3, offset 0.000026, synch distance 0.12448 maverick.mcc.ac.uk: stratum 2, offset 0.017359, synch distance 0.05569 ntp1.ja.net: stratum 1, offset 0.017014, synch distance 0.00258, refid 'GPS' hydrogen# From the output we can confirm that we are synchronized correctly, running one stratum lower than the server (stratum 3), as expected. This also shows that the root of our servers is a stratum-1 hardware device. At this point, we are happy that NTP is configured and working on the server, which means we can copy the configuration around the remaining machines. Build the Local NTP Server Now that all the clients are synchronized to a public server, we'll "upgrade" hydrogen so that it now becomes our "master" server instead. We don't have any specialized hardware available to connect to, so instead we'll use its own clock as the reference device. In reality, all this means is that NTP will query the system clock and use whatever value it returns. Although we have chosen hydrogen to be our NTP server, it isn't really critical which one is usedobviously, all the other systems must be able to see it on the network. It also makes sense to run it on a server, rather than one of the desktops, even though NTP doesn't generate too much overhead. The NTP daemons are already running on this machine, so the first task is to stop them: hydrogen# /etc/init.d/xntpd stop hydrogen# As we are using the local clock as the reference source, we ought to make sure it's adjusted correctly. This is a manual task and should be done before we start to configure NTP, although in our case, since we've only just stopped it, the clock should already be correct: hydrogen# date <correct time> hydrogen# Next we need to alter ntp.conf and replace the public time server's entries with the one for our local clock. After the changes have been made, our file looks like the one shown below: hydrogen# cat /etc/inet/ntp.conf # # Server config for host hydrogen # (expected to operate via local clock at stratum 10) # server 127.127.1.0 fudge 127.127.1.0 stratum 10 driftfile /var/ntp/ntp.drift hydrogen# Let's look at the entries we've used. First we've specified the server, which is the onboard clock. We only have one of them so it is instance 0. Looking at Table 19.1, we can see that the local clock is device type 1. All this gives us a server address of 127.127.1.0. By default, the clock will advertise itself at stratum 3, but we want to set it to a lower stratum (using the "fudge" keyword). This is because we don't want to advertise it as a relatively high-stratum server. Also, we may at some point connect a better time source, for example, a public time server. If we forget to update the clock entry it could confuse NTP into thinking it was a better server than the new time source. NTP uses the highest stratum server it has access to, regardless of whether it is stratum 3, 10, or whatever, so we are OK to have the clock set low even if it is the only device. (The internal code is actually written to force every other device to be used before querying this one, as it is known to be relatively inaccurate on many systems.) Lastly, we've included a drift file, which is the same one as the previous configuration. Now that everything has been configured, we can restart the NTP daemon by running its start-up script: hydrogen# /etc/init.d/xntpd start hydrogen# Checking NTP on the Server Once the daemon has started, let's run ntpq again to display the server list. This time the output should be similar to that shown below: hydrogen# ntpq -np remote refid st t when poll reach delay offset disp ==================================================================== 127.127.1.0 127.127.1.0 10 l 8 64 1 0.00 0.000 15885.0 hydrogen# This shows that the server is the local clock and is operating at stratum 10. We haven't yet synchronized with it, which we know because there isn't a "*" character in the first column. We can see that "reach" is set to octal 1 (binary 00000001), which indicates we have only seen the first pollthe reason for this is that it has just started running. "Delay" and "offset" are both set to 0, which is really what we should expect as we are connected to the local machine and, therefore, shouldn't have any network-related delays. Interestingly, "dispersion" is very high at the moment. Again, this is because the daemon has just started running and has not synchronized yetit should settle down to a correct level when it has. If we run ntpq again some time later, we'll see something similar to the following. Here we can see we've synchronized with the server, "reach" indicates we've seen the last six polls, and "dispersion" has fallen to a realistic level: hydrogen# ntpq -np remote refid st t when poll reach delay offset disp ================================================================== *127.127.1.0 127.127.1.0 10 l 8 64 77 0.00 0.000 10.01 hydrogen# Let's also run ntptrace to follow the chain of servers back to the primary time source: hydrogen# ntptrace localhost: stratum 11, offset 0.000072, synch distance 0.0022 127.127.1.0: *Timeout* hydrogen# This confirms that we are synchronized with the local clock and we are running at stratum 11, one level lower than the clock as expected. At this point we are happy that NTP is configured and working on hydrogen. (The time-out simply occurs because the clock cannot be queried in the same way as a "genuine" time device would.) Configuring the Clients Now we can move on to the remaining machines on the network and synchronize them to the new server. To do this, we need to alter each machine's existing configuration file and restart the NTP daemon, just as we did for hydrogenwe'll use helium for this example. The configuration file, ntp.conf, after we've made the changes is shown here: helium# cat /etc/inet/ntp.conf # # Client config file. # server timeserver driftfile /var/ntp/ntp.drift hydrogen# This uses the time server entry that we defined for hydrogen earlier in the section "Host Names" on page 461. We've also used the same drift file as the previous setup. If the local clock is out of synchronization with the server by more than 1,000 seconds (around 16 minutes), NTP will not start. To ensure that this is not a problem, we'll set it to approximately the correct time on the server before we start. We can do this using either rdate or ntpdate. Ntpdate will use the same service as the NTP daemon, so it's also a good check that everything is communicating, but ensure that the daemon isn't already running or they will conflict (we'll stop it first to make sure): helium# /etc/init.d/xntpd stop helium# ntpdate hydrogen 24 Jun 12:31:32 ntpdate[13362]: adjust time server 192.168.22.1 offset 0.000432 sec helium# Now we can start the NTP daemon by running the start-up script provided: helium# /etc/init.d/xntpd start helium# Checking the Clients First, we'll let NTP "settle" down. This should take around 10 minutes (8 passes, multiplied by the poll time of 64 seconds) before we acknowledge synchronization (although it will take much longer, perhaps a day, before the frequency error starts to stabilize). When we check ntpq, we can see that "reach" is set to 377, indicating that all the polls have worked. The delay and offset values are low, as we would expect running over the local network, and we have successfully synchronized with the server named "timeserver," which is advertising itself as a stratum-11 server: helium# ntpq -p remote refid st t when poll reach delay offset disp =============================================================== *timeserver LOCAL(0) 11 u 33 64 377 0.37 -0.165 0.05 helium# An association number identifies every connection to a server. If we wished to check further and monitor the individual poll times for a particular server, we could query its association ID. First we need to obtain the correct ID, which we can do with ntpq: helium# ntpq -c as ind assID status conf reach auth condition last_event cnt =========================================================== 1 51316 9614 yes yes none sys.peer reachable 1 helium# Now we can query the association: helium# ntpq -c "rv 51316" status=9614 reach, conf, sel_sys.peer, 1 event, event_reach srcadr=timeserver, srcport=123, dstadr=192.168.22.1, dstport=123, keyid=0, stratum=11, precision=-18, rootdelay=0.00, rootdispersion=10.25, refid=LOCAL(0), reftime=bd1d9e73.31595000 Mon, Jul 17 2000 16:02:11.192, delay=0.38, offset=-0.26, dispersion=0.02, reach=377, valid=8, hmode=3, pmode=4, hpoll=6, ppoll=6, leap=00, flash=0x0<OK>, org=bd1d9e87.c4ca2000 Mon, Jul 17 2000 16:02:31.768, rec=bd1d9e87.c4e7c000 Mon, Jul 17 2000 16:02:31.769, xmt=bd1d9e87.c4c60000 Mon, Jul 17 2000 16:02:31.768, filtdelay= 0.38 0.38 0.37 0.37 0.35 0.37 0.35 0.27, filtoffset= -0.26 -0.26 -0.26 -0.23 -0.21 -0.17 -0.14 -0.17, filterror= 0.02 0.99 1.97 2.94 3.92 4.90 5.87 6.85 helium# Most of the output here refers to values for some of the internal values used by NTP, but the last three lines show the last eight poll times for delay, offset, and dispersion, which can be useful to check. Running ntptrace will again trace the hierarchy back to the root server, and confirm we are communicating with "timeserver" (hydrogen) and that the stratum levels have been adjusted as we saw earlier running ntpq: helium# ntptrace localhost: stratum 12, offset 0.000023, synch distance 0.01082 timeserver: stratum 11, offset -0.000185, synch distance 0.01041 127.127.1.0: *Timeout* helium# Checking the date on any system is a quick way of confirming that we have achieved clock synchronization: helium# rsh hydrogen date; date Mon Jun 26 15:22:19 BST 2000 Mon Jun 26 15:22:19 BST 2000 helium# The only task left to do now is to check hydrogen's system clock on a regular basis and, depending on the required accuracy, make any changes to it. NTP will propagate the changes around the system from there. The Final Configuration As the last step, we could amalgamate both these configurations; in other words, use a local server that synchronizes with a number of public time servers, while providing the ability to fall back to its local clock if the connection to the public servers failed. To do this, we could use the following configuration file on the server: hydrogen# cat /etc/inet/ntp.conf # # Server config for host hydrogen # server ntp2a.mcc.ac.uk server ntp.cs.strath.ac.uk server salmon.maths.tcd.ie server 127.127.1.0 fudge 127.127.1.0 stratum 10 driftfile /var/ntp/ntp.drift hydrogen# The clients, on the other hand, would use their existing configuration file as this already synchronizes with hydrogen. This means they will be using the following configuration file: helium# cat /etc/inet/ntp.conf # # Client config file. # server timeserver driftfile /var/ntp/ntp.drift helium# Check the Final Configuration To check that everything is working correctly, we'll run both ntpq and ntptrace from "timeserver" and one of the clients, say helium. On hydrogen, we can see that we are once more synchronized with 130.88.202.49 at stratum 2, while ntptrace shows that we are correctly running at stratum 3 and also that we can traced back to the level-1 server: hydrogen# ntpq -p remote refid st t when poll reach delay offset disp ========================================================================== 127.127.1.0 127.127.1.0 10 l 27 64 377 0.00 0.000 10.01 *130.88.202.49 194.81.227.227 2 u 57 64 377 16.94 2.481 3.22 +130.159.196.118 130.159.248.11 3 u 57 64 377 23.65 3.875 2.73 +134.226.81.11 134.226.81.3 2 u 57 64 337 122.02 -42.051 6.58 hydrogen# hydrogen# ntptrace localhost: stratum 3, offset 0.000026, synch distance 0.12448 maverick.mcc.ac.uk: stratum 2, offset 0.017359, synch distance 0.05569 ntp1.ja.net: stratum 1, offset 0.017014, synch distance 0.00258, refid 'GPS' hydrogen# Running the same commands on helium confirms that hydrogen is advertising at stratum 3 and that helium itself is set to 4: helium# ntpq -p remote refid st t when poll reach delay offset disp ========================================================================= *timeserver maverick.mcc.ac 3 u 18 64 377 0.35 -3.583 0.64 helium# helium# ntptrace localhost: stratum 4, offset 0.000041, synch distance 0.11223 timeserver: stratum 3, offset -0.002903, synch distance 0.10863 maverick.mcc.ac.uk: stratum 2, offset 0.012206, synch distance 0.05421 ntp1.ja.net: stratum 1, offset 0.012867, synch distance 0.00275, refid 'GPS' helium# | 
