Difference between revisions of "NTP Server"

From Earlham CS Department
Jump to navigation Jump to search
(Explanation)
 
(20 intermediate revisions by 3 users not shown)
Line 1: Line 1:
proto.cs.earlham.edu is an ntp timeserver for Earlham's network. The time value it outputs come from some weighted average of two inputs. The first input is a NIST server located in Chicago. The second input is a GPS device on the fourth floor of dennis (in a box connected to the 4th floor lab's closet).
+
proto.cs.earlham.edu is an ntp timeserver for Earlham's network. The time value it outputs come from some weighted average of two inputs. The first input is a NIST server located in Chicago. The second input is a GPS device on Dennis roof (in the electric-style box connected to the 4th floor lab closet).
  
<p align="center"> '''Setup Procedure (Serverside)''' </p>
+
=Explanation=
 +
Our Earthmate GPS, in position outside
 +
 
 +
[[File:GpsPic.jpg]]
 +
 
 +
==Setup Procedure (Serverside)==
 
Plug the GPS device into proto via USB.
 
Plug the GPS device into proto via USB.
 
Make a symbolic link from the presence of the USB device on proto to /dev/gps0.
 
Make a symbolic link from the presence of the USB device on proto to /dev/gps0.
Line 7: Line 12:
 
Restart the ntp daemon.
 
Restart the ntp daemon.
  
<p align="center"> '''Setup Procedure (Clientside)''' </p>
+
==Setup Procedure (Clientside)==
Insert this line into your ntp.conf: "server 159.28.230.6"
+
Insert these lines into your ntp.conf: "server 159.28.230.6 prefer" and "fudge 159.28.230.6 stratum 1"
 
+
The prefer parameter is optional, but its effect of weighting proto's signal more heavily in the ultimate time value is beneficial.
<p align="center"> '''Debugging''' </p>
+
The fudge line is also optional, but its effect of notifying ntp's algorithms of proto's stratum 1 quality is beneficial.
 
 
 
 
<p align="center"> '''Explanation of Choices''' <\p>
 
Since it is easy to configure one's time to a NIST timeserver and NIST uses highly accurate atomic clocks, you might wonder why we bother with the GPS. The locality of the GPS elimintates network latency and network jitter as sources of error. While, for Earlham, the GPS signal may be more accurate, it is also less reliable. Somebody might accidentally unplug the GPS and HIP might not notice for a few hours/days, whereas the NIST server's importance means that attentive, skillful people would notice problems sooner. Considering this worst case scenario, and the fact that the different between 3:17:30 and 3:17:20 100% of the time is less important to most people than the difference between 4:17:30 and 3:17:30 0.28 percent of the time, it is best to mix the inputs.
 
 
 
<p align="center"> '''The Configuration File''' <\p>
 
 
 
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
 
  
#This is a backup from an intermediate stage of modification.
+
==Managing the Client's NTP daemon==
driftfile /var/lib/ntp/ntp.drift
+
The "/etc/init.d/ntpd" command controls the ntp daemon. Passing it one of the parameters {restart, stop, start}, e.g. "/etc/init.d/ntpd restart" does exactly what you might imagine. After editing the configuration file to include proto as a server, you will need to restart the daemon for the changes to take effect.
  
 +
==Testing and Debugging==
 +
Type 'ntpdc' into your shell. That should give you an interpreter to which you will give the command 'peers'. If there is the value "=proto.cs.earlham.edu" in the first column of the output, then you are getting your time from proto.
  
# Enable this if you want statistics to be logged.
+
==Explanation of Choices==
statsdir /var/log/ntpstats/
+
Since it is easy to configure one's time to a NIST timeserver and NIST uses highly accurate atomic clocks, you might wonder why we bother with the GPS. The locality of the GPS reduces network latency and network jitter as sources of error. While, for Earlham, the GPS signal may be more accurate, it is also less reliable. Somebody might accidentally unplug the GPS and HIP might not notice for a few hours/days, whereas the NIST server's importance means that attentive, skillful people would notice problems sooner. Considering this worst case scenario, and the fact that the different between 3:17:30 and 3:17:20 100% of the time is less important to most people than the difference between 4:17:30 and 3:17:30 0.28 percent of the time, it is best to mix the inputs
  
statistics loopstats peerstats clockstats
+
==Troubleshooting==
filegen loopstats file loopstats type day enable
+
GPS attached via USB connection:
filegen peerstats file peerstats type day enable
+
*GPS -> black USB -> gray USB -> proto
filegen clockstats file clockstats type day enable
 
  
 +
The daemon is located at "/etc/init.d/ntp status".
  
# You do need to talk to an NTP server or two (or three).
+
NTP logs are located at "/var/log/daemon.log". In one circumstance the gps0 device was reporting that it wasn't found. It turned out that ttyUSB0 (the GPS) wasn't recognized despite it being plugged in. I unplugged and replugged the GPS. It worked.
#server ntp.your-provider.example
 
  
# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will
+
To check if NTP is functioning correctly execute "ntpq -p" on clients or "ntpq -p proto.cs.earlham.edu" from within the CS subnet. The "when" field should be less than the "poll" field.
# pick a different set every time it starts up. Please consider joining the
 
# pool: <http://www.pool.ntp.org/join.html>
 
#the following four were defaults
 
  
server 216.171.120.36  #chicago NIST
+
==Clients==
server 127.127.20.0 mode 0 prefer # the gps is a server
+
Only the 159.28.0.0 subnet can access Proto's NTP.
fudge 127.127.20.0 flag1 1 flag2 0 flag3 1 time2 0.600
 
  
#server 127.127.1.0        #local clock, just in case gps is down
+
ACLs
#fudge 127.127.1.0 stratum 10
 
# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
 
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
 
# might also be helpful.
 
#
 
# Note that "restrict" applies to both servers and clients, so a configuration
 
# that might be intended to block requests from certain clients could also end
 
# up blocking replies from your own upstream servers.
 
  
 +
clusters?
  
#Allows all users on the Earlham network, characterized by IPv4 address
+
==The Server-Side Configuration File on Proto==
#starting with 159.28, to synchronize.
+
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
restrict default kod nomodify notrap
 
restrict 159.28.0.0 mask 255.255.0.0 nomodify notrap
 
  
# Local users may interrogate the ntp server more closely.
+
#This is a backup from an intermediate stage of modification.
restrict 127.0.0.1
+
driftfile /var/lib/ntp/ntp.drift
restrict ::1
 
  
# Clients from this (example!) subnet have unlimited access, but only if
+
# Enable this if you want statistics to be logged.
# cryptographically authenticated.
+
statsdir /var/log/ntpstats/
#restrict 192.168.123.0 mask 255.255.255.0 notrust
 
  
 +
statistics loopstats peerstats clockstats
 +
filegen loopstats file loopstats type day enable
 +
filegen peerstats file peerstats type day enable
 +
filegen clockstats file clockstats type day enable
  
# If you want to provide time to your local subnet, change the next line.
+
server 216.171.120.36  maxpoll 4 minpoll 4 #chicago NIST
# (Again, the address is an example only.)
+
server 127.127.20.0 mode 0 prefer # the gps is a server
#broadcast 159.28.230.6
+
fudge 127.127.20.0 flag1 1 flag2 0 flag3 1 time2 0.600
 +
 +
# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
 +
# details. The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
 +
# might also be helpful.
 +
#
 +
# Note that "restrict" applies to both servers and clients, so a configuration
 +
# that might be intended to block requests from certain clients could also end
 +
# up blocking replies from your own upstream servers.
 +
  
# If you want to listen to time broadcasts on your local subnet, de-comment the
+
#Allows all users on the Earlham network, characterized by IPv4 address
# next linesPlease do this only if you trust everybody on the network!
+
#starting with 159.28, to synchronize.
#disable auth
+
restrict default ignore
#broadcastclient
+
restrict 159.28.0.0 mask 255.255.0.0 nomodify notrap
 +
   
 +
# Local users may interrogate the ntp server more closely.
 +
restrict 127.0.0.1
 +
restrict ::1

Latest revision as of 08:46, 20 May 2015

proto.cs.earlham.edu is an ntp timeserver for Earlham's network. The time value it outputs come from some weighted average of two inputs. The first input is a NIST server located in Chicago. The second input is a GPS device on Dennis roof (in the electric-style box connected to the 4th floor lab closet).

Explanation

Our Earthmate GPS, in position outside

GpsPic.jpg

Setup Procedure (Serverside)

Plug the GPS device into proto via USB. Make a symbolic link from the presence of the USB device on proto to /dev/gps0. Use the configuration file in the footer of this page or edit your configuration file to contain many of its ideas. Restart the ntp daemon.

Setup Procedure (Clientside)

Insert these lines into your ntp.conf: "server 159.28.230.6 prefer" and "fudge 159.28.230.6 stratum 1" The prefer parameter is optional, but its effect of weighting proto's signal more heavily in the ultimate time value is beneficial. The fudge line is also optional, but its effect of notifying ntp's algorithms of proto's stratum 1 quality is beneficial.

Managing the Client's NTP daemon

The "/etc/init.d/ntpd" command controls the ntp daemon. Passing it one of the parameters {restart, stop, start}, e.g. "/etc/init.d/ntpd restart" does exactly what you might imagine. After editing the configuration file to include proto as a server, you will need to restart the daemon for the changes to take effect.

Testing and Debugging

Type 'ntpdc' into your shell. That should give you an interpreter to which you will give the command 'peers'. If there is the value "=proto.cs.earlham.edu" in the first column of the output, then you are getting your time from proto.

Explanation of Choices

Since it is easy to configure one's time to a NIST timeserver and NIST uses highly accurate atomic clocks, you might wonder why we bother with the GPS. The locality of the GPS reduces network latency and network jitter as sources of error. While, for Earlham, the GPS signal may be more accurate, it is also less reliable. Somebody might accidentally unplug the GPS and HIP might not notice for a few hours/days, whereas the NIST server's importance means that attentive, skillful people would notice problems sooner. Considering this worst case scenario, and the fact that the different between 3:17:30 and 3:17:20 100% of the time is less important to most people than the difference between 4:17:30 and 3:17:30 0.28 percent of the time, it is best to mix the inputs

Troubleshooting

GPS attached via USB connection:

  • GPS -> black USB -> gray USB -> proto

The daemon is located at "/etc/init.d/ntp status".

NTP logs are located at "/var/log/daemon.log". In one circumstance the gps0 device was reporting that it wasn't found. It turned out that ttyUSB0 (the GPS) wasn't recognized despite it being plugged in. I unplugged and replugged the GPS. It worked.

To check if NTP is functioning correctly execute "ntpq -p" on clients or "ntpq -p proto.cs.earlham.edu" from within the CS subnet. The "when" field should be less than the "poll" field.

Clients

Only the 159.28.0.0 subnet can access Proto's NTP.

ACLs

clusters?

The Server-Side Configuration File on Proto

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
#This is a backup from an intermediate stage of modification.
driftfile /var/lib/ntp/ntp.drift
# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats 
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server 216.171.120.36  maxpoll 4 minpoll 4 #chicago NIST
server 127.127.20.0 mode 0 prefer # the gps is a server
fudge 127.127.20.0 flag1 1 flag2 0 flag3 1 time2 0.600

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

#Allows all users on the Earlham network, characterized by IPv4 address
#starting with 159.28, to synchronize.
restrict default ignore
restrict 159.28.0.0 mask 255.255.0.0 nomodify notrap

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1