Understanding system time
Keeping time, and ensuring that it's kept accurately, is a common function on computer systems. It occurs under the hood of your system and is a given when establishing servers. It's the system administrator's responsibility to ensure that the foundational infrastructure is in place to support time on computers.
In this guide we'll explore the configuration options to allow the network time protocol (NTP) to manage time. We'll also introduce a tool to examine statics from time sources and cover a few troubleshooting exercises using network tools.
Using the block diagram below, we'll start our discussion with the hardware box, moving to sources of time and finish with more in-depth details on management – but let's begin with the BIOS and hardware clocks.
If you've ever set up the BIOS you will have been presented with menu selections for establishing date and time. This establishes the clock time on the PC's motherboard.
This clock answers to many names: a complementary metal oxide semiconductor (or CMOS) clock, a BIOS clock, a motherboard clock or as in our drawing a hardware clock.
The CMOS battery keeps the clock ticking when there's no AC power to the board. In times of old the clock and battery may have been contained in a CMOS module that plugged into a 16-pin chip socket.
The hardware clock is, in turn, the source of time for the system clock that's maintained by the operating systems. When an OS starts, the system clock seed time is taken from the hardware clock and the OS then takes over.
These two clocks operate independently and are not synchronised, which means it's possible to reboot and discover the system time isn't accurate because the hardware clock is a poor timekeeper. How far the hardware clock time drifts can result in problems, which we'll discuss later.
Managing time
The system clock can call for assistance to get the time right using a network time protocol daemon (ntpd). This daemon sends a request to more accurate external time source for time checks, and using the data provided the daemon feeds the system clock a drift factor to keep the time in sync with the external sources.
One of the limitations of ntpd is how far out of whack the system clock and the external sources are allowed to be. If the hardware clock and system clock differ by approximately 1K seconds or more, the daemon assumes one of the two time keepers is misconfigured and the daemon will fail.
Since the hardware clock is the system clock's seed time, it becomes important for the hardware clock to be within the 1K limits. One mechanism to compensate for the hardware clock is ntpdate. The program ntpdate uses an external time source to provide a one-time adjustment to the system's clock for accuracy.
From the command line you can provide ntpdate with a time source. You must make sure no time service is running, then type the following:
ntpdate 0.pool.ntp.org
On some OSes, before the ntpd starts, ntpdate uses the external time source to provide a one-time kick to the system's clock for accuracy. For the list of time source URLs or IPs for ntpdate, look in the /etc/ntp/step-tickers file.
When ntpd takes over and provides drift compensation, it isn't faced with a system clock that's so far out it can't pull it back on time. The hardware clock can continue to run amok or get some help, but we'll discuss that a little later.
Time sources
The world of external time sources is divided into levels or strata numbered according to accuracy. The closer to the originating source of time, the lower the stratum number. Getting time from a source that's directly connected is considered stratum 0.
If that time has been provided to other distribution points, which in turn pass the time on to other points, then the stratum number is incremented, to a maximum of 15.
The source of most accurate times are atomic clocks, which can be carried in satellites or be ground-based. Satellites have multiple atomic clocks on board to ensure they are keeping accurate time. The global positioning system (GPS) requires the time accuracy to put a plane on a runway and not off in the bush.
Ground-based atomic clocks have been a source of time in the telecommunication industry for decades. Accurate time is important to ensure that information transmitted as bits can be decoded as acceptable bits when received at the other end.
Working with NTP config files
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
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
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.
Read more on this >> Tecspot Media Blog
Original source: How to keep your Linux system clock accurate.
No comments:
Post a Comment