How do I setup a local NTP server?

I installed NTP server on Ubuntu Server 10.04 using:

sudo apt-get install ntp

The NTP daemon seems working and listening on the 123 port.

However, I was not able to get the time from another machine:

sudo ntpdate -u my_ntp_server
23 Nov 18:48:41 ntpdate[2990]: no server suitable for synchronization found

Is there any necessary configurations to do?


Solution 1:

Here's a good how-to from Ubuntu forums: http://ubuntuforums.org/showthread.php?t=862620

Flagrant copy-pasta:

HOWTO: Set Up an NTP Server

This tutorial describes how to set up your machine as a local Network Time Protocol (NTP) server and/or how to use the NTP daemon to regularly maintain an accurate system time.

What is NTP?

The Network Time Protocol (NTP) is a protocol designed for accurately synchronizing local time clocks with networked time servers. The NTP network of time servers is set up as a hierarchical manner, such that any user can enter the system as a server at some level (see the Wikipedia page for more details).

The NTP hierarchy is separated into different levels, called clock strata. The most accurate level, Stratum 0, is reserved for atomic clocks, etc. The next level, Stratum 1, is generally used by networked machines locally connected to the Stratum 0 clocks. Stratum 2...15 are NTP machines that are connected, in turn, to lower level clocks and each other.

This guide describes how to synchronize accurately with Stratum 1 and 2 machines, and maintain as accurate of system clock as possible throughout the day. Sections are also included on how to allow your machine to operate as a Stratum 2/3 server for other machines on your local network.

Do I have to make an NTP server?

No... absolutely not! If you're satisfied with the clocks on your network having some unknown difference from the standard time (and each other), then you do not have to set up an NTP server. I set one up on my laptop in order to synchronize multiple machines on a local network within < 1 ms for a bioengineering experiment. There are various other advantages, in addition, which are described below.

Motivation:

Regularly, unmodified Ubuntu boxes use ntpdate (/usr/sbin/ntpdate) to synchronize the clock periodically with some external time server. This approach synchronizes the clock with a coarse resolution (typically once a day).

Computer clocks are imperfect, and will drift from the (correct) time server during the day. Furthermore, drift rates in the clocks of different computers differ, such that by the end of the day significant differences may exist between different locally networked machines, which may interfere with certain operations (for instance, ever have a makefile complain when moving source code among different machines?).

It is possible to run the NTP daemon locally on a machine on your network. This has multiple advantages: first, the NTP daemon gradually "learns" the drift rate of your local machine, and can correct for it throughout the day. Synchronization with upper level time servers takes place multiple times a day, and many different time servers may be used simultaneously to make the synchronization more accurate. In this way, the NTP daemon acts as an accurate time client, keeping your system clock as close to the the standard time as possible.

In addition to maintaining an accurate system clock, the NTP daemon allows a machine on your network (if you would like) to operate as an NTP time server. Doing so will allow other machines on your local network to synchronize with your LAN time server in a very quick and accurate manner, since network latency is minimized. In this way, the differences in clocks between machines on your network is kept as minimal as possible. Mac, and even Windows boxes are also able to synchronize with an NTP server, should you set one up.

There are other, less personal, motivations for setting up a machine as an NTP server. First, doing so may decrease the strain on higher level NTP servers, since other machines on your LAN may synchronize with a locally established time server. Also, ntpdate has been deprecated in favor of using the -q flag for ntpd (which mimics its functionality). Thus, even if you do not want to run ntpd constantly in the background, ntpdate will eventually be replaced with ntpd, so you may want to become familiar with it now

How to Maintain an Accurate System Clock with ntpd

  1. Install the NTP daemon

First, install the NTP daemon (ntpd):

sudo aptitude install ntpd

As was previously mentioned, ntpd can act both as a client (synchronizing your system time) and as a server (providing accurate time for other machines).

Optionally, you may also want to remove the previous (deprecated) time synchronization program, ntpdate. Perhaps it may be wiser to do so after you have ntpd working

sudo aptitude remove ntpdate
  1. Configure the daemon properly

The configuration file for ntpd is located at /etc/ntp.conf. The default Ubuntu file probably requires some modification for optimal performance.

The first section you may want to modify is the list of servers to synchronize with. The default section probably looks as follows:

# You do need to talk to an NTP server or two (or three).
server ntp.ubuntu.com

In order to get the most accurate time possible, it is preferable to communicate with multiple different NTP servers, and keep them as close to your physical location as possible. There are various different server lists online, probably the best is located here. There is some debate over the proper number of servers to use. One is better than two, and three or more probably is a good idea, so long as you don't go too overboard. An example of a few time servers that I used follows:

server nist1-dc.WiTime.net iburst
server ntp0.mcs.anl.gov
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org

Once a few good servers have been found, add them to the list, putting 'iburst' after the most promising one. For instance:

server nist1-dc.WiTime.net iburst

This will cause ntpd to synchronize very quickly with this server after starting up. Otherwise, ntpd will slowly tend to drift towards agreement with the server list (as is its nature), and it may take 15-20 minutes to synchronize well enough to act as a time server for the rest of your network.

Also, add a few extra lines to the bottom of your servers list to provide your current local time as a default should you temporarily lose Internet connectivity:

server 127.127.1.0
fudge 127.127.1.0 stratum 10

This will prevent any nastiness if you're running ntpd on a laptop or other machine with intermittent periods of disconnection from the Internet.

All in all, the server list should look similar to the following (this is mine, your servers will probably be different):

# You do need to talk to an NTP server or two (or three).
server nist1-dc.WiTime.net iburst
server ntp0.mcs.anl.gov
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org
server 127.127.1.0
fudge 127.127.1.0 stratum 10
  1. Make sure the configuration works

Now that you have a proper server list in your /etc/ntp.conf file, it is time to run the daemon and see if you synchronize properly! Make sure you have an active Internet connection, and then run:

sudo /etc/init.d/ntp restart

Next, monitor your system log to see if you synchronize with a time server:

tail -f /var/log/syslog

In about 10-15 seconds (or up to 15-20 minutes if you forgot to put 'iburst' after your favorite server), you should see something like the following in your system log:

Jul 17 16:50:22 hostname ntpd[22402]: synchronized to 140.221.9.20, stratum 2

If this message never comes, you have not yet properly synchronized with the NTP server network. Check the list of NTP peers you are communicating with using the following:

ntpq -c lpeer

If the 'delay', 'offset', and 'jitter' fields are non-zero and you haven't synchronized, it probably means that you just need to wait a while. Check again that you've inserted the 'iburst' argument to your servers list! My peers, for reference, look something like the following:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*milo.mcs.anl.go 192.5.41.40      2 u    4   64   77   46.213   67.753   2.207
-europium.canoni 193.79.237.14    2 u   63   64   37   97.375   71.020   1.875
-dtype.org       69.25.96.13      2 u    2   64   77   86.956   69.178   1.804
+smtp130.junkema 216.218.254.202  2 u    2   64   77   87.266   67.677   0.916
+kechara.flame.o 216.218.254.202  2 u    -   64   77   89.183   68.717   1.713
-host2.kingrst.c 99.150.184.201   2 u    -   64   77   24.306   62.121   2.608
 LOCAL(0)        .LOCL.          10 l   59   64   37    0.000    0.000   0.002
  1. Share! (optional)

Once ntpd is running and is synchronized with the time servers you have selected, you may set it up in order to act as a time server for other machines. To do so, add a section like the following to /etc/ntp.conf:

# Allow LAN machines to synchronize with this ntp server
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
restrict 192.168.2.0 mask 255.255.255.0 nomodify notrap
# You may add as many (or few) CIDR address blocks to allow to synchronize with your machine as you'd like. I included those commonly used with Linksys (192.168.1.*) and SMC (192.168.2.*) routers.
  1. Synchronize! (optional)

Once you've set up an NTP server using steps 1-4, you can synchronize the other machines on your network with your server in various manners. I outline a couple of them below:

ntpd:

If you have ntpd installed on another machine, you can use your first server in the servers list of your ntp.conf file, or can synchronize one time with the -q option, as follows:

ntpd -q [IP address of your server]

ntpdate:

If you still have ntpdate installed on another machine, you may use it to synchronize with your server as follows:

ntpdate [IP address of your server]

Note: if you are running ntpd on a machine and for some reason still want to use ntpdate to set the time, you must use the -u option.

Windows:

Windows machines use a simplified version of NTP called Simple Network Time Protocol (SNTP), and can synchronize with NTP servers. In order to synchronize with your new server, double click on the time and go to the "Internet Time" tab. Put the IP address of your server in the "Server" field. I have attached a screenshot of Windows XP synchronizing with a LAN time server, should anybody be interested.

That's it! The entire process is not hard, but can be confusing to somebody who hasn't dealt much with the NTP network before. I hope this helps! Let me know if you have any problems setting up your server.

Mike

Links

I found the following links helpful... you may, too!

  • https://help.ubuntu.com/7.10/server/C/NTP.html
  • http://linuxwave.blogspot.com/2007/0...tp-server.html
  • http://lists.ntp.isc.org/pipermail/q...er/011889.html
  • http://www.linuxhomenetworking.com/w...Fntp.conf_File
  • http://www.ntp.org/ntpfaq/NTP-a-faq.htm

Solution 2:

There are many links about this and it seems to me that they complicate the procedure. In my case I have one machine that acts as a proxy server and a firewall, and all my others connect to the internet through it. I did not want to open ports on the firewall. Therefore the proxy server must be the time (ntp) server and the other machines (clients) get the time from it.

You must install ntp on all the machines, and you should install ntpq on all of them as well.

First, see if ntp is working. By default, ntpd (the ntp daemon) will be running as soon as it is installed, and the defaults should work. However, ntp does not work instantly, so wait a while. Then, the command:

ntpq -c lpeer

should give you output that looks something like this:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+golem.canonical 193.79.237.14    2 u  170 1024  377  140.458   -0.655   3.234
*gatekeeper.tss. 204.123.2.72     2 u  608 1024  377   84.650    2.168   0.471

or:

ntpq --numeric --peers

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+91.189.89.199   193.79.237.14    2 u  652 1024  377  140.151   -0.242   2.821
*66.7.96.1       204.123.2.72     2 u   64 1024  377   85.074    2.409   0.963

If so, you're connected and your time server is getting the time. If not, use

ps -e | grep "ntp" 

to be sure that ntp in running, and try again. Also try restarting ntp:

sudo /etc/init.d/ntp restart

it may take some "time" (sorry!) before the connection is established. The daemon does not poll the servers very often. The "when" column in the output above shows the time in seconds since the server was polled.

Now, you have to make the time server send the time to your other machines.

Edit the file /etc/ntp.conf on the server. You have to add a line for your network. In my case, I have a 10.0.0.0 network. In the ntp.conf file, I added the line:

broadcast 10.255.255.255

You must add a broadcast line for each segment of your network. If your network is simple like mine, one line like the above is all you need. Now, restart ntp using the command above, and check again using ntpq, and you should see:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+golem.canonical 193.79.237.14    2 u   70 1024  377  140.151   -0.242   2.821
*gatekeeper.tss. 204.123.2.72     2 u  506 1024  377   84.650    2.168   0.241
 10.255.255.255  .BCST.          16 u    -   64    0    0.000    0.000   0.002

Voila, it's broadcasting.

Now, you must make every client machine get the time from your broadcasting server. On each one, edit the file:

/etc/ntp.conf

and you will see some lines specifying servers.

add a line

server 10.10.10.1

or whatever the address of your server is. Then restart ntp on the client machine using the above command. Alternatively, you can get the process ID and just kill it, and run it again. Whatever.

Then, after sufficient time, check with ntpq:

ntpq --numeric --peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.10.10.1      66.7.96.1        3 u  123 1024  377    0.430    1.022   1.831

and you can see that the client is using the time server.

This takes some time.

Solution 3:

The accepted answer (as for July 2018) did not work for me. This other method worked fine on Ubuntu 16.04 LTS on July 2018:

Install NTP, if not installed:

sudo apt-get update
sudo apt-get install ntp

Edit configuration file to allow NTP service to receive requests:

sudo nano /etc/ntp.conf --syntax=sh

Uncomment this line:

# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
# broadcast 192.168.111.255

to:

# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
broadcast 192.168.111.255

Restart NTP service:

sudo /etc/init.d/ntp restart

Now your NTP server must be working and allow another computers to synchronize with yours. Any of the above tests, like the ntpdate -u YourComputer should work OK.

To check if NTP services are running: To confirm your ntp services are at least running, it is getting time from upstream server, run

$ sudo ntpq -p


     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 time.cloudflare .POOL.          16 p    -   64    0    0.000    0.000   0.001
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.001
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.001
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.001
....#further output omitted