NTP on a Debian 6 server

This post is an update to my original in March 2011.

NTP is useful to set the time of LAN devices. The correct time is essential for several services. I installed ntp on an almost-always-connected server, which will in turn broadcast the correct time to other devices on my LAN.

internet ntp servers  <--->  my net ntp client / LAN ntp server  <--->  my LAN ntp clients

The ntp program is both client and server (those used to be separate packages). The same ntp gets installed on all devices. You change the settings in the /etc/ntp.conf file. The version of ntp on those devices isn't important - different versions of ntp interact well together (unlike, say, different versions of the deluge torrent client/server)

These instructions are for debian 6, running as root. For Ubuntu, you need to prepend most commands with 'sudo'

1. Install NTP with the following command:
   

   apt-get install ntp

2. Edit the server's /etc/ntp.conf file (if needed). If you want your device to get time from the default internet time servers (in most cases, this is exactly what you want), then skip this step and make no changes.
   
   In my case, however, my server is both a client of those upstream internet time servers AND a time server to my LAN. Your LAN probably does not need a timeserver - I'm doing this for fun.
   

   ## Around Line 48
   # If you want to provide time to your local subnet, change the next line.
   # (Again, the address is an example only.)
   #broadcast 192.168.123.255
   
   # Since my LAN is 192.168.1.0, the corresponding broadcast address is at 192.168.1.255
   broadcast 192.168.1.255

3. No changes to /etc/hosts.allow and /etc/hosts.deny are needed to limit access to ntpd. Access controls are set by the /etc/ntp.conf file, they default to nobody has any access, and we didn't change those rules.
4. xinted and dnsmasq do not interact with ntpd, and no special configuration is required.
5. Firewall rules to open udp port 123 for ntp sync messages. Normally, this won't be necessary. Since the ntp client sends the first packet to the upstream internet server, and outbound packets usually are not blocked, the firewall should automatically let the server's response through.
   
   If an ntp client has a really locked-down firewall (blocking outgoing traffic), then open the client's UDP port 23 to outgoing traffic.
   

   iptables -A OUTPUT -p udp --sport 123 -j ACCEPT

   
   If you run a LAN-facing NTP server, then of course you must ensure that LAN-interface UDP port 23 is open to that same inbound traffic from your clients. (your -i interface name will be different)
   

   iptables -A INPUT -i lan0 -p udp --dport 123 -j ACCEPT 

   
   If you run an exposed internet-facing NTP server, then you should really be working with ntp.org for security, and to help support the ntp infrastructure!
   
   In my case, no firewall changes were needed at all. My firewall blocks inbound packets from the internet, not LAN-only packets, and not outbound-packets (or responses).
6. Restart/update the firewall (how you do that is up to you), and then restart ntp to reload the changed config file. Let's test ntp to see if it's working:
   

   $ ntpq -p
        remote           refid      st t when poll reach   delay   offset  jitter
   ==============================================================================
   -w1-wdc.ipv4.got 10.0.77.54       4 u  396 1024  377   30.567    1.853   2.901
   *ntp3.junkemailf 209.81.9.7       2 u  465 1024  377   64.788   -0.072   1.269
   +vimo.dorui.net  208.90.144.52    3 u  633 1024  377   32.876   -1.081  30.206
   +aeolus.seobeo.c 193.67.79.202    2 u  184 1024  377  110.840    0.577   1.790
    192.168.1.255   .BCST.          16 u    -   64    0    0.000    0.000   0.000
   

   Looks correct. The first character of each row (*/+/-) is the status of each upstream server. See the explanation. The 'when' column is the number of seconds since the last check of that server. The'poll' column is the number of seconds between checks. The first four rows are upstream internet servers. The last row is the LAN broadcast, which is why it doesn't have an upstream status.
7. The other ntp clients on the LAN need to be modified to listen for the new ntp server. Left alone, they will pull time from the upstream internet time servers (good). But, of course, I now have a server broadcasting time, so let's set each device on my LAN to listen for it. Plus, I still want them to get time from upstream in case my ntp server goes down or starts sending bad time.
   
   Log in to each device, and look at their /etc/ntp.conf (though it may be in a different location or names differently).
   
   Here's an example /etc/ntp.conf change from an Ubuntu system on the LAN, starting at around Line #15. We added the LAN ntp server, and marked it as the preferred source. We added minpoll to the internet servers to increase the time between pollings.
   

   # Specify one or more NTP servers.
   server kiwkak.dyndns.org prefer
   
   # Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
   # on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
   # more information.
   server 0.ubuntu.pool.ntp.org minpoll 12
   server 1.ubuntu.pool.ntp.org minpoll 12
   server 2.ubuntu.pool.ntp.org minpoll 12
   server 3.ubuntu.pool.ntp.org minpoll 12

   Restart ntp (in debian 'service ntp restart'. For ubuntu 'sudo service ntp restart') to reload the new configuration file.
   
   Let's also take a loot at their ntp status:
   

   $ ntpq -p
        remote           refid      st t when poll reach   delay   offset  jitter
   ==============================================================================
   *adsl-76-229-175 184.105.182.7    3 u   28   64  377    0.274    0.805   0.209
    ntp1.Rescomp.Be 169.229.128.214  3 u  838 1024    3   63.979    3.262   0.424
    cheezum.mattnor 129.7.1.66       2 u  818 1024    3   34.490    0.145  25.810
    host2.kingrst.c 204.9.54.119     2 u  789 1024    3   22.359    0.721  17.671
    vf1.bbnx.net    128.4.1.1        2 u  824 1024    3   68.227   -0.820   1.466
   

   
   This looks good. See how the local server is preferred, and gets checked more often than the backup upstream servers. And the backup upstreams are reachable, but not currently used.
8. The server itself may not always be the network router/firewall. I automagically switching between server between router and non-router roles using my kingbaron script. I use a script and two config files to change how ntp runs based on if the system is a router (Network King, runlevel 3) or just a LAN client (Faithful Baron, runlevel 4). The decision logic operates in runlevel 2.
   
   Create two .conf files, one for each runlevel. Let's call them /etc/ntp-king.conf and /etc/ntp-baron.conf. Look at all the .conf stuff above for the contents of those files.
   
   Use the following command once to automatically prevent ntp from starting in runlevel 2 (the decision logic level), and to stop ntp if you manually switch to runlevel 2 due to a loss of connectivity or for maintenance:

   update-rc.d ntp stop 2

   
   Add the following patch to /etc/init.d/ntp to restart ntp with the appropriate config files upon runlevel changes.
   

   test -x $DAEMON || exit 5    # Insert after this line
   
   current_runlevel=echo $(runlevel | cut -d' ' -f2)
   if [ current_runlevel -eq "3" ]; then
        NTPD_OPTS="$NTPD_OPTS -c /etc/ntp-king.conf"
   elif [ current_runlevel -eq "4" ]; then
        NTPD_OPTS="$NTPD_OPTS -c /etc/ntp-baron.conf"
   

   This covers the common use cases (booting, manual force of decision logic), but doesn't cover everything - if I manually switch to runlevels 3/4/5, ntp won't automatically check the config.