NTP Server Configuration

Internal Network Time Protocol Server

This is a great service to deploy next. The service can benefit the whole network, and is relatively easy to set up.

Basically, the goal is to make an internal server contact some usable trustworthy NTP servers, such as the public pool of servers. (However, for a classroom environment where many new networks may be created, there might be an authorized private server that should be getting used instead. Check the usual sources (project documentation, lab assistant, course instructor) to see if there is a local private server that should be used.)

System address plan (first half-octet) has this at “.14”.

Note: This is not a publicly accessible Network Time Protocol Server.Update: server is now meant to be publicly accessible, so ignore that last sentence. If the system is only meant for private, internal use, then the System address plan (early addresses) has that at “.12”. (and, ignore this next sentence...) To keep things as simple as possible, this guide is starting off with a server that is just meant for private use. If you really want to publicly offer Network Time Protocol time, and you don't wish to make a private server first, and you wish to follow the System address plans, then adjust the upcoming documentation to use “.12” instead of “.14”.

Creating and configuring a “child image”

At this point, almost all of the standard steps of creating and configuring a “child image” will apply well. The only exception is the little bit that is related to setting the clock (including any handling of NTP). Skip those steps, but follow the others.

  • Follow the steps described by creating and configuring a “child image” except for the portion about handling NTP/clocks.
    • Update: server is now meant to be publicly accessible, so ignore this paragraph. Also, there will be no need to update the file(s) related to the public/external DNS zone configuration, since this server will be internal-only. So just skip the instructions to update those specific file(s). (However, do update the files related to the private/internal DNS zone configuration.)
Customizing a local NTP server
Overview: server choice
OpenNTPD
Convenient. Comes with OpenBSD.
ntp.org offerings

This is largely unrecommended, because of the following:

Comparison of OpenNTPD to ntp.org offering showed ntp.org offering uses 192,870 lines of code, compared to OpenNTPD's 2,898 lines of code. So Theo's comparison was really an underestimation in Theo de Raadt's commentary in OpenBSD-Tech discussion of OpenNTPD.

Based on Theo's claim that much of that is “unknown or largely unused code”, it seems the extra code size might not provide much extra functionality. See also: OpenBSD FAQ on OpenNTPD which discusses ntpd.org. For instance, the OpenBSD FAQ says, “There are applications where the ntp.org ntpd is more appropriate; however it is felt that for a large majority of the users, OpenNTPD is more than sufficient.”

Systemd-timesyncd

Arch Linux Wiki: OpenNTPD page, “See also” section states, “If you do not require strict timekeeping then Systemd-timesyncd is easier to setup.”

(However, from the name of that software, presumably it requires systemd, which is not an option that is as widely available... In late 2015, this was not typically found on non-Linux systems.)

Adjusting NTP configuration
sudo ls -l /etc/ntpd.conf*
cat /etc/ntpd.conf
cpytobak /etc/ntpd.conf

Remember, the /etc/ntpd.conf file may just be a symlink. (That is the case if this guide has been followed.) If that is the case, then that filesystem object isn't extremely difficult to re-create.

ls -l /etc/ntpd.conf*
cpytobak /etc/ntpd.conf*
sudo ln -f -s /etc/ntpd.conf.pubsvr /etc/ntpd.conf.local
ls -l /etc/ntpd.conf*
sudo ntpd -n
sudo pkill ntpd
sudo time ntpd -svf /etc/ntpd.conf.local
echo ${?}
ntpctl -s all
  • (The “ntpd -sv” might take a little bit, which shouldn't be too surprising since this guide uses the time command. Some experimentation has shown that may commonly take 48-49 seconds, although it would not be at all surprising if that speed may depend on various factors like Internet connection speed and how close and responsive the upstream “time servers” are.)
Sample: This could have been the output of “ tail /var/log/daemon | grep -i ntpd | grep -v grep
MMM DD hh:07:23 hostname ntpd[####]: ntp engine ready
MMM DD hh:08:15 hostname ntpd[####]: peer ###.##.#.## now valid
MMM DD hh:08:15 hostname ntpd[####]: peer ##.###.###.### now valid
MMM DD hh:08:15 hostname ntpd[####]: peer ###.###.##.# now valid
MMM DD hh:10:53 hostname ntpd[#####]: adjusting local clock by -77.295535s
MMM DD hh:12:27 hostname ntpd[#####]: adjusting local clock by -76.825535s
MMM DD hh:18:21 hostname ntpd[1377]: clock is now synced
MMM DD hh:19:25 hostname ntpd[####]: peer ###.#.##.### now valid
MMM DD hh:27:52 hostname ntpd[####]: peer ###.#.##.### now valid
MMM DD hh:34:06 hostname ntpd[####]: peer ###.#.##.### now valid

(Those last 3 lines all had the same IPv4 address.)

Troubleshooting
0/## peers valid, clock unsynced
DNS issues

If the output is showing the names of pools, rather than the names of systems that are in the pool, then DNS may be broken. Notice in the following actual example output, there is only one peer, and it is pool.ntp.org, the name of an NTP server.

0/1 peers valid, clock unsynced

peer
   wt tl st  next  poll          offset       delay      jitter
not resolved from pool pool.ntp.org
    1  2  -   15s   15s             ---- peer not valid ----

Try making connections to the systems. Can you ping any of those systems, or any other systems? (If DNS is broken, then “0... peers valid” can be the result.)

Just let ntpd run for a bit. Check back in a few minutes. Doing so has been known to jump from 0/20 peers valid, clock unsynced to 16/20 peers valid, clock unsynced.

  • If the output of the “next” column (the fourth columns) simply remains zero, maybe that means the peer is not going to be retried?
  • You may wish to see if that address shows up in /var/log/daemon file.
    • Information may be added after some time, like a few after NTP started. Sometimes the messages have come in a bit more than 5 minutes after the OpenNTPD server logged that it was started up.
    • A remote source being marked as “peer 2001:db8:: now invalid” (or IPv4peer 203.0.113.10 now invalid”) is not really a terrible thing; the peer may become valid later. However, a phrase of “bad peer ”) may be a bit more condemning.
  • Restarting the NTP client may be helpful (perhaps just to cause the NTP to retry the DNS request).
  • If a constraint is being used, you may wish to check HTTPS connections to that constraint. (Use a text-mode web client; some are mentioned at web-based file transfers, but for interactive (non-automated) use, a full-featured web browser might be more pleasant (as you don't need to bother with manually cleaning up a saved temporary file). Some browsers are mentioned by the section about “installing more software”.)
  • Even if HTTPS works when tested, HTTPS constraints have been known to break NTP. (At the time of this writing, in October of 2015, constraints were a fairly new feature of OpenNTPD.) Consider just removing the constraints, and see if results are better.
  • Try: “ rdate -vp 198.51.100.14 ”.
##/## peers valid, clock unsynced

This discusses if the number of peers is non-zero. (Earlier text addressed if the number of peers is zero.)

This may take several minutes. Check back later. (Maybe about 10 minutes later.)

Some sample output
hostname:~/$ ntpctl -s all
8/8 peers valid, clock unsynced

peer
   wt tl st  next  poll          offset       delay      jitter
##.##.###.# 0.us.pool.ntp.org
    1  8  2    5s    8s         1.793ms    79.856ms     0.926ms
##.###.##.### 1.us.pool.ntp.org
    1  8  2    5s    8s         3.873ms   121.202ms     9.331ms
###.###.###.## 2.us.pool.ntp.org
    1  7  2    0s    8s        -6.598ms   111.490ms     1.818ms
###.###.###.# 3.us.pool.ntp.org
    1  8  2    5s    8s         4.054ms    96.676ms     2.694ms
###.###.#.### 0.ca.pool.ntp.org
    1  8  1    5s    8s         1.713ms   102.837ms     5.383ms
###.##.###.## 1.ca.pool.ntp.org
    1  8  3    2s    5s         7.293ms    97.593ms     2.811ms
###.###.##.### 2.ca.pool.ntp.org
    1  8  2    5s    8s        -3.377ms   115.918ms     1.963ms
###.###.##.### 3.ca.pool.ntp.org
    1  8  2    6s    9s       -11.328ms    98.878ms     3.199ms
hostname:~/$ rdate -vp 127.0.0.1
rdate: Ignoring NTP server with alarm flag set
rdate: Unable to get a reasonable time estimate
hostname:~/$ ntpctl -s all
8/8 peers valid, clock synced, stratum 2

peer
   wt tl st  next  poll          offset       delay      jitter
##.##.###.# 0.us.pool.ntp.org
    1 10  2    0s   30s        -0.086ms    81.427ms     3.834ms
##.###.##.### 1.us.pool.ntp.org
    1 10  2    0s   32s         0.635ms   121.876ms    12.756ms
###.###.###.## 2.us.pool.ntp.org
    1 10  2    0s   33s        -9.279ms   112.634ms     3.034ms
###.###.###.# 3.us.pool.ntp.org
    1 10  2    0s   32s         1.403ms    98.115ms     2.761ms
###.###.#.### 0.ca.pool.ntp.org
 *  1 10  1    0s   32s        -1.286ms   105.084ms     4.965ms
###.##.###.## 1.ca.pool.ntp.org
    1 10  3    0s   32s         3.325ms    95.975ms     1.287ms
###.###.##.### 2.ca.pool.ntp.org
    1 10  2    0s   34s        -5.712ms   116.538ms     4.561ms
###.###.##.### 3.ca.pool.ntp.org
    1 10  2    0s   32s       -13.424ms    99.117ms     2.310ms
hostname:~/$ rdate -vp 127.0.0.1
DOY MMM DD hh:mm:ss TZN YYYY
rdate: adjust local clock by 0.000005 seconds
hostname:~/$

The reference to an “alarm” can be seen in RFC 1059: Network Time Protocol (Version 1) Specification and Implementation, page 16 (and elsewhere, page 44), and is simply a name of the state/condition of having an unsynchronized clock. The way to clear the alarm is to get the bits to stop indicating that the clock is unsynchronized.

The earlier error was corrected simply by waiting a bit.

Supporting the remaining network

If this server is synchronized, then, great. Now, make sure that another system can reach this server. Go onto another system (such as the computer running the “DHCP/IPv4 server” software), and have its configuration file point to the newly created local NTP server.

ls -l /etc/ntpd.conf*
cpytobak /etc/ntpd.conf*
sudo ln -f -s /etc/ntpd.conf.privsvr /etc/ntpd.conf
cpytobak /etc/ntpd.conf.privsvr
echo ${VISUAL}
ls -l /etc/ntpd.conf*
sudoedit /etc/ntpd.conf.privsvr
sudo ntpd -n
Firewall handling
Firewall on the NTP server
OpenBSD PF
cpytobak /etc/pf.conf
echo| sudo -n tee -a /etc/pf.conf
echo \#Permit required outgoing proto NTP| sudo -n tee -a /etc/pf.conf
echo pass out quick proto udp from self to any port ntp keep state| sudo -n tee -a /etc/pf.conf
echo| sudo -n tee -a /etc/pf.conf
secho \#Permit incoming NTP| sudo -n tee -a /etc/pf.conf
echo pass in  quick proto udp to self port ntp keep state| sudo -n tee -a /etc/pf.conf
sudo pfctl -nf /etc/pf.conf
sudo pfctl -nf /etc/pf.conf&&sudo pfctl -ef /etc/pf.conf
“Firewall” virtual machine
OpenBSD PF
cpytobak /etc/pf.conf
echo| sudo -n tee -a /etc/pf.conf
echo \#Begin configuration to support NTP server\(s\)| sudo -n tee -a /etc/pf.conf
echo \table \<tbl_ntpSvr\> \{ 2001:db8:1::14 198.51.100.14 \}| sudo -n tee -a /etc/pf.conf
echo| sudo -n tee -a /etc/pf.conf
echo \# Permit authorized outgoing proto NTP| sudo -n tee -a /etc/pf.conf
echo pass in  quick on \$vmSvrs_if proto udp from \<tbl_ntpSvr\> to any port ntp \| sudo -n tee -a /etc/pf.conf
echo \\tkeep state| sudo -n tee -a /etc/pf.conf
echo pass out quick on \$ext_if proto udp from \<tbl_ntpSvr\> to any port ntp keep state| sudo -n tee -a /etc/pf.conf
echo| sudo -n tee -a /etc/pf.conf
echo \# Permit incoming NTP \(possibly from public\)| sudo -n tee -a /etc/pf.conf
echo pass in  quick on ! \$vmSvrs_if proto udp to \<tbl_ntpSvr\> port ntp keep state| sudo -n tee -a /etc/pf.conf
echo pass out quick on   \$vmSvrs_if proto udp to \<tbl_ntpSvr\> port ntp keep state| sudo -n tee -a /etc/pf.conf
sudo pfctl -nf /etc/pf.conf
sudo pfctl -nf /etc/pf.conf&&sudo pfctl -ef /etc/pf.conf
Testing NTP
(Re-)Starting the NTP server
sudo pkill ntpd
sudo ntpd -svf /etc/ntpd.conf.local
echo ${?}
ntpctl -s all

If that works well, then the next trick is to get other systems to use the private NTP server.

Don't plan on widespread multi-platform support via DHCP

Despite DHCP seeming to support this, such support is not widespread. Braiam's answer to neirbowj's SuperUser.com question: “Which clients accept DHCP option 42 to configure their NTP servers? indicates that only ISC DHCP supports the option. As a specific example, Oliver Salzburg's answer to his own SuperUser.com question about Windows clients not using a NTP server specified via DHCP indicates that Microsoft Windows ignores the option.

(This is currently redundant with info at vmdhcpd4.htm)

Using other NTP software

To check whether the firewall is allowing NTP traffic, you could use another program, such as:

rdate -p pool.ntp.org

If the time is significantly off (e.g., this has been seen if time is off by about an hour), performing a faster update with:

sudo rdate pool.ntp.org
Adjusting system startup

e.g. OpenBSD:

(Currently untested...)

[ -f /etc/ntpd.conf.local ]&&cpytobak /etc/ntpd.conf.local
echo ntpd_flags=\"-s -v -f /etc/rc.conf.local \&\"| sudo -n tee -a /etc/rc.conf.local