Ubuntu Server 18.04 – Keeping your clock in sync with NTP

How to Setup a Node.js Application Using PM2

It’s incredibly important for Linux servers to keep their time synchronized, as strange things can happen when a server’s clock is wrong. One issue I’ve run into that’s especially problematic is file synchronization utilities, which will exhibit strange behavior when there are time issues. However, Ubuntu servers feature the NTP client and server within the default repositories to help keep your time in sync. If it’s not already installed, all you should need to do is install the ntp package:

sudo apt install ntp 

Once installed, the ntp daemon will immediately start and will keep your time up to date. To verify, check the status of the ntp daemon with the following command:

systemctl status ntp 

The output should show that ntp is running:

Checking the status of the NTP service

If all you wanted was a working NTP client, then you’re actually all set. The default configuration is fine for most. But further explanation will help you understand how this client is configured. You’ll find the configuration file at /etc/ntp.conf, which will contain some lines of configuration detailing which servers your local ntp daemon will attempt to synchronize time with:

pool 0.ubuntu.pool.ntp.org iburst 
pool 1.ubuntu.pool.ntp.org iburst 
pool 2.ubuntu.pool.ntp.org iburst 
pool 3.ubuntu.pool.ntp.org iburst 

As you can see, our server will synchronize with Ubuntu’s time servers if we leave the default configuration as it is. For most users, that’s perfectly fine. There’s nothing wrong with using Ubuntu’s servers. However, if you have a great number of clients in your organization, it may make sense to set up your own NTP server so that only one server is talking to the outside world instead of every one of your nodes. Essentially, this is how you can become a friendly neighbor online. If you have hundreds of workstations in your organization that are configured to check Ubuntu’s NTP servers, that’s quite a bit of traffic those servers will need to endure. To be fair, Ubuntu’s servers won’t have any trouble handling this traffic, though it’s a nice gesture to configure one server in your network to synchronize with Ubuntu’s time servers, then configure your local nodes to synchronize with just your local server. If everyone did this, then Ubuntu’s time servers would see far less traffic.

Setting up a local NTP server is actually quite straightforward. All you need to do is designate a server within your network for this purpose. You could even use the internet gateway you set up in the previous section if you wanted to. Once you have that server set up to synchronize, you should be able to configure your local nodes to talk to that server and synchronize their clocks with it.

Before we get ahead of ourselves though, we should make sure that the server we installed NTP on is synchronizing properly. This will give us a chance to use the ntpq command, which we can use to view statistics about how well our server is synchronizing. The ntpq -p command should print out statistics we can use to verify connectivity:

Example output from the ntpq -p command

To better understand the output of the ntpq -p command, I’ll go through each column. First, the remote column details the NTP servers we’re connected to. The refid column refers to the NTP servers that the remote servers are connected to. The st column refers to a server’s stratum, which refers to how close the server is from us (the lower the number, the closer, and typically, better). The t column refers to the type, specifically whether the server is using unicast, broadcast, multicast, or manycast.

Continuing, the when column refers to how long ago it was since the last time the server was polled. The poll column indicates how often the server will be polled, which is 64 seconds for most of the entries in the example screenshot. The reach column contains the results of the most recent eight NTP updates. If all eight are successful, this field will read 377. This number is in octal, so eight successes in octal will be represented by 377. When you first start the ntp daemon on your server, it may take some time for this number to reach 377.

Finally, we have the delay, offset, and jitter columns. The offset column refers to the delay in reaching the server, in milliseconds. Offset references the difference between the local clock and the server’s clock. Finally, the jitter column refers to the network latency between your server and theirs.

Assuming that the results of the ntpq -p command look good and your server is synchronizing properly, you already essentially have an NTP server at your disposal, since there is little difference between a client and a server. As long as your server is synchronizing properly and port 123 is open between them through the firewall, you should be able to reconfigure your nodes to connect to your server, by changing the pool addresses in your client’s configuration (within /etc/ntp.conf), to point to either the IP address or the Fully Qualified Domain Name (FQDN) of your NTP server instead of Ubuntu’s servers. Once you restart the ntp service on your other nodes, they should start synchronizing with the master server.

Before we close out this chapter, there is one additional change you should consider implementing to the /etc/ntp.conf file, however. Look for the following line within that file:

#restrict 192.168.123.0 mask 255.255.255.0 notrust 

Change this line by first uncommenting it, changing the network address and subnet mask to match the details for your network, and then remove the notrust keyword at the end. The line should look similar to the following, depending on your network configuration:

restrict 192.168.1.0 mask 255.255.255.0 

So, what does this option do for us? Basically, we’re limiting access to our NTP server to local clients only, and we’re only allowing read-only access for security purposes.

Now that you have a working NTP server, feel free to experiment and point your existing nodes to it and have them synchronize. Depending on the size of your network, a local NTP server may or may not make sense, but at the very least, NTP should be installed on every Linux workstation and server to ensure proper time synchronization. In most cases, the workstation version of Ubuntu will already be configured to synchronize to the Ubuntu time servers, but when it comes to the server version, NTP isn’t typically installed for you.

Comments are closed.