Difference between revisions of "NTP Server"
(→Explanation) |
|||
| (10 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 Dennis roof (in the electric-style box connected to the 4th floor lab 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 | + | |
| + | =Explanation= | ||
| + | Our Earthmate GPS, in position outside | ||
| + | |||
| + | [[File:GpsPic.jpg]] | ||
==Setup Procedure (Serverside)== | ==Setup Procedure (Serverside)== | ||
| Line 8: | Line 12: | ||
Restart the ntp daemon. | 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" | 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 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. | 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. | 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. | 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 | 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== | ==The Server-Side Configuration File on Proto== | ||
| Line 51: | Line 72: | ||
#Allows all users on the Earlham network, characterized by IPv4 address | #Allows all users on the Earlham network, characterized by IPv4 address | ||
#starting with 159.28, to synchronize. | #starting with 159.28, to synchronize. | ||
| − | restrict default | + | restrict default ignore |
restrict 159.28.0.0 mask 255.255.0.0 nomodify notrap | restrict 159.28.0.0 mask 255.255.0.0 nomodify notrap | ||
Latest revision as of 07: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).
Contents
Explanation
Our Earthmate GPS, in position outside
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
