That wraps up the three blocks of time in our diagram: hardware, managing and sources. Let's circle back around for a sequel to managing time by opening a terminal for some more management.
First check to see if a time keeper program is installed and running. There are a number of possible ways to accomplish this task. Here are some suggestions...
Using the command line, query the OS software manager, for example yum or apt-get, to determine if the time software is installed.
You can scan running processes to grep for the network time protocol (NTP) pattern. You could also use the systemctl or service tool to determine program status. Additionally, you can cull directories with a whereis looking for the program or pursue directories in search of files you know will be there if the program exists.
If the support for NTP is not installed on your system, use your software managing tool installation command. If you're using Red Hat this is as follows:
sudo yum install ntpd
and for a Debian variant:
sudo apt-get install ntp
For experimenting with the time daemon, check that it is not running with either of the following:
sudo systemctl stop ntpd
or
sudo service ntp stop
Note that the daemon that supports time may be scripted with ntp or ntpd. If you find that ntp in a command doesn't work, try appending the 'd' suffix and running the command again!
WARNING: Before you start this tutorial you'll want to rename the original time configuration file to something else, and leave it untouched so that you can restore it afterwards. DO NOT PLAY WITH THE ORIGINAL FILE. Create a dummy file with a configuration for working through this tutorial at mv /etc/ntp.conf /etc/ntp.conf.org
So, using whatever text editor you were weaned on, edit/create a file called /etc/ntp.conf. We're going to create a file that has all the configuration options needed but commented out.
We'll remove the octothorpe (pound sign #) and the text Line as instructed, to expand the options in the configuration file. It's important to save the file after each change.
Using a second terminal window, we'll run commands to start the time daemon and probe the service's workings with query tools. By adding the configuration options line by line, you will witness how the daemon's operation is impacted.
Saved your original file safely under a different name? Here's what to enter in your test file as /etc/ntp.conf:
server 0.pool.ntp.org
#Line 1 restrict default kod nomodify notrap nopeer noquery
#Line 2 restrict -6 default kod nomodify notrap nopeer noquery
#Line 3 restrict 127.0.0.1
#Line 4 restrict -6 ::1
#Line 5 server 127.127.1.0
#Line 6 fudge 127.127.1.0 stratum 10
#Line 7 driftfile /var/lib/ntp/drift
Now make sure to save the file. We'll come back to the config file a few times to remove comments and save. We'd suggest keeping the file open and do a save from one terminal window.
Open a second terminal. If you are running SElinux in enforced mode, the new file will also need the proper context. This is done by referencing the original config file:
chcon –reference=/etc/ntp/ntp.conf.org /etc/ntp.conf
Start the time daemon using either
sudo systemctl start ntpd
or
sudo service ntp start
Let's do some probing using the command-line time query tool ntpq. This program is a utility used to monitor the operation and performance of the NTP daemon (ntpd). The commands to enter can be found in the screenshot from the output of our test system below.
The -n switch enables a DNS lookup of 0.pool.ntp.org. The URL used in our example is a front for a pool of servers. Don't expect to get the same IP shown in our output as it will vary.
Just after start it will look like this:
[root@fedora19]# ntpq -n -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
142.137.247.109 209.51.161.238 2 u 2 64 1 43.446 3.550 0.000
[root@fedora19]# ntpq -c assoc
ind assid status conf reach auth condition last_event cnt
===========================================================
1 58621 9024 yes yes none reject reachable 2
After 4 minutes, it will look like this:
[root@fedora19]# ntpq -n -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
*142.137.247.109 209.51.161.238 2 u 4 64 17 43.300 4.534 0.838
[root@fedora19]# ntpq -c assoc
ind assid status conf reach auth condition last_event cnt
===========================================================
1 58621 963a yes yes none sys.peer sys_peer 3
The commands were issued once when the daemon was started and again four minutes later. The line around the condition field indicates that the source is being used as a peer.
The line around the remote field is to draw attention to the asterisk. This indicates that the daemon has successfully peered with the source for time input.
For more information on the ntpq tool, the de facto resource for all documentation is on the University of Delaware website.
What do you do if the daemon is not peering with a source? This is a good time to break out the packet sniffer to see if our daemon is functioning.
This will enable us to check if the daemon is sending out a time request and receiving a reply. You can confirm the port number used by ntp or other services by examining the /etc/services file – see the red No.1 in the screenshot for the output of this command:
sudo tcpdump -i port 123
The output of tcpdump displays the daemon's call to the external time source every minute. There don't appear to be any replies being received. A quick check of the local firewall reveals a closed port 123 on the firewall. Look at the same tcpdump output: a reply was received once the port was opened.
If you don't see requests being sent then the issue rests with the daemon; it may not have started. Check your install and configuration file.
Securing ntpd
The ntp daemon by default is open and very chatty when queried (see the green No.2 in screenshot for the output). This information enables other computers to get the status and more details. Reading the output is a simple way to tell what kernel a system is running.
The security conscious may want to curtail the daemon's propensity to speak out. Edit the /etc/ntp.conf configuration file by removing the # and Line 1-4 text. You should now have a total of five lines. Don't forget to save the file after making the changes. Restart the daemon to read the configuration changes using
sudo systemctl restart ntpd
or
sudo service ntp restart
Lines 1-2 (counting the very first line as Line 0, of course – we're computer geeks!) allow time synchronisation with another source but don't allow the source to interrogate or make changes to the daemon. Lines 3-4 enable loopback access and disable others. The reason for two config lines is to cover off configuration for IPv4 and IPv6 protocols.
Running the same query commands as before, we find that the daemon isn't responding to requests. Edit the /etc/ntp.conf configuration file by removing the # and Line 5-7 text, and restart the daemon to read the configuration changes.
Lines 5-6 enable the daemon to use the hardware clock as a time source, if external sources aren't available. Line 7 enables the daemon to record the hardware clock's drift from system clock in a file. This information assists the daemon on power-down restarts. A simple ntp print query displays the local time source in the output – see the blue No. 3 in the screenshot for the output:
mv /etc/ntp.conf.org /etc/ntp.conf
Using a text editor, examine /etc/ntp.conf for commented entries. If you plan to use this config file for your installation, you'll need to add your server selections and/or remove the default entries.
Let's finish off back at the hardware clock. The hardware clock values are read with
hwclock -r
and written from the system clock to the hardware clock with:
hwclock -w
The man pages suggest running the write command periodically to compensate for the hardware clock drift.
There you have it, taking care of business and working over time – an examination of Father Time provided by the ntp daemon. The ntp program follows the client-server model and can be used to set time or even to distribute time as a broadcast. Those titbits of time distribution configuration you can discover in the original configuration file.
