Network Time Protocol

From ArchWiki
Revision as of 00:59, 7 February 2010 by Littlebear (Talk | contribs) (Cron Job instead of Daemon)

Jump to: navigation, search

Template:I18n links start Template:I18n entry Template:I18n entry Template:I18n links end This article describes two different possibilities to synchronize the Linux software clock (system clock) to Internet time servers. Openntpd is explained, then the original ntpd method is explained. For more information on computer timekeeping, see Time.

OpenNTPD

OpenNTPD is a free, easy to use implementation of the Network Time Protocol. It provides the ability to sync the local clock to remote NTP servers and can act as NTP server itself, redistributing the local clock. OpenNTPD is primarily developed by Henning Brauer as part of the OpenBSD Project, and is a new implementation of the NTP protocol. It is also much easier to configure and use than ntpd.

First, the OpenNTPD package must be installed (available in the Arch Linux community repository):

# pacman -S openntpd

The default configuration is actually usable if all you want is to sync the local computer. For more detailed settings, the Template:Filename file must be edited:

To sync to a particular server, uncomment and edit the "server" directive. You can find the server's URL in your area at www.pool.ntp.org/zone/@.

server ntp.example.org

The "servers" directive works the same as the "server" directive, however, if the DNS name resolves to multiple IP address, ALL of them will be synced to. The default, "pool.ntp.org" is working and should be acceptable in most cases.

pool.ntp.org

Any number of "server" or "servers" directives may be used.

If you want the computer you run OpenNTPD on to also be a time server, simply uncomment and edit the "listen" directive.

For example:

listen on *

will listen on all interfaces, and

listen on 127.0.0.1

will only listen on the loopback interface.

However, your time server will only begin to serve time after it has synchronized itself to a high resolution. This may take hours, or days, depending on the accuracy of your system.

If you would like to run OpenNTPD at boot, add Template:Codeline the DAEMONS variable in your Template:Filename following your network daemon. If oenntpd is being used to set local system time only, it may be safely backgrounded like so:

@openntpd

To see the status of NTP syncing, visit Template:Filename and look for entries with "ntpd".

OpenNTPD adjusts the clock by small amounts at a time. It is designed this way to prevent sudden, large time fluctuations in your system, which could adversely affect system services (e.g., cron jobs). Thus, it can take some time to correct the time.

If your clock is off by more than 180 seconds you can try "Template:Codeline" in the console. If ntpd is already running, you can simply restart it with Template:Codeline, as the Arch openntpd package uses the "-s" flag by default. See Template:Codeline for more info. You can also set the system clock to as close to possible to the actual time and then let OpenNTPD fine tune the time.

Troubleshooting

Error adjusting time

If you find your time set incorrectly and in log you see:

openntpd adjtime failed: Invalid argument

Try:

ntpd -s -d

Increasing time shift

Starting openntpd in the background could lead to synchronization errors between the actual time and the time stored on your computer. If you recognize an increasing time difference between your desktop clock and the actual time, try to start the openntpd daemon normal and not in the background.

Initialization Failure

Openntpd may fail to initialize properly if it is started before the network is fully configured. In some cases you may want to remove Template:Codeline from the DAEMONS array in Template:Filename and add the following line to Template:Filename:

(sleep 300 && /etc/rc.d/openntpd start) &

This will wait 5 minutes before starting openntpd, which should give the system sufficient time to set up the network properly. If your network settings change often, you may also consider restarting the daemon regularly with cron.

If you are using netcfg, you can also start/stop openntpd as a POST_UP/PRE_DOWN command in your network profile:

POST_UP="/etc/rc.d/openntpd start || true"
PRE_DOWN="/etc/rc.d/openntpd stop || true"

Of course, you will have to specify this manually for each network profile.

Using NetworkManager dispatcher

OpenNTPD can be brought up/down along with a network connection through the use of NetworkManager's dispatcher scripts. Place the following slightly modified Template:Filename script as Template:Filename

#!/bin/bash

CONF=/etc/conf.d/openntpd

. /etc/rc.conf
. /etc/rc.d/functions

[ -f $CONF ] && . $CONF

PID=`pidof -o %PPID /usr/sbin/ntpd`
case "$2" in
  up)
    stat_busy "Starting OpenNTPD"
    [ -z "$PID" ] && /usr/sbin/ntpd $PARAMS
    if [ $? -gt 0 ]; then
      stat_fail
    else
      PID=`pidof -o %PPID /usr/sbin/ntpd`
      echo $PID >/var/run/openntpd.pid
      add_daemon openntpd
      stat_done
    fi
    ;;
  down)
    stat_busy "Stopping OpenNTPD"
    [ ! -z "$PID" ]  && kill $PID &>/dev/null
    if [ $? -gt 0 ]; then
      stat_fail
    else
      rm_daemon openntpd
      stat_done
    fi
    ;;
  *)
    echo "usage: $0 {up|down}"  
esac
exit 0

Cron Job instead of Daemon

Running OpenNTPD as a daemon may not always be desirable if you have a special way you configure your network, or if you have a bad hardware clock. You can add a cron job that will update the system clock hourly, daily..., set the hardware clock, and remove the time drift file. Open your root crontab by typing "crontab -e" into terminal and (for example) to have your time set at 12:03am daily:

03  00  *   *   *       ntpd -s && hwclock -w && rm /var/lib/hwclock/adjtime

ntpd

# pacman -S ntp

/etc/ntp.conf

The very first line of your ntp.conf file should contain a line such as the following:

restrict default noquery notrust nomodify

This essentially restricts everyone from modifying anything. Following this, you need to let ntpd know what you want to let through into your NTP server. Here is where you would specify any other IP addresses you would like to synchronize on your NTP server. For example:

restrict 1.2.3.4
restrict 192.168.0.0 mask 255.255.255.0 nomodify

This tells ntpd that 1.2.3.4 and all IP addresses from the 192.168.0.0 range will be allowed to synchronize on this server, but they will not be allowed to modify anything. All other IP addresses in the world will still obey the default restrictions (the first line in the ntp.conf).

Now, is where the stratum 2 servers that our server will synchronize with come into play. The lines in ntp.conf will be used to tell ntpd what servers we would like to use for synchronizing (these are just examples; use ntp servers that are closest to your location). Please see http://ntp.isc.org/bin/view/Servers/NTPPoolServers for a list a closer servers.

server ntp1.cs.wisc.edu
server ntp3.cs.wisc.edu
server ntp3.sf-bay.org

Unless you have a good reason not to, it is advisable to use the pool.ntp.org servers: http://www.pool.ntp.org/. Alternatively, a list of ntp servers is available at http://www.eecis.udel.edu/~mills/ntp/clock2a.html. Please pay attention to the Access Policies.

If we left it alone right now, we would never connect to a server because the response from any of the three servers listed above would never be allowed back into our server due to the fact that our default restrict statement would be in use (since we did not add the servers to our lesser restrictions (like we did with 127.0.0.1 and the subnet of 192.168.0.0).

To correct this, enter the following lines in ntp.conf:

restrict ntp1.cs.wisc.edu noquery nomodify
restrict ntp3.cs.wisc.edu noquery nomodify
restrict ntp3.sf-bay.org noquery nomodify

This will allow the response from the above servers into our system so our local clock can be synchronized. The noquery restriction will not allow any of the above three servers to query for information from our server. The nomodify restriction will not allow the three servers to modify anything (synchronization will still take place).

The only thing left to do is add the drift file (which keeps track of yours clocks time deviation). and the log file location:

driftfile /etc/ntp.drift
logfile /var/log/ntp.log

The complete file will look like this:

# default restrictions
restrict default noquery notrust nomodify

# override the default restrictions here
restrict 10.1.1.0 mask 255.255.255.0 nomodify

# public NTP servers to sync with (all stratum 2)
server ntp1.cs.wisc.edu
server ntp3.cs.wisc.edu
server ntp3.sf-bay.org

restrict ntp1.cs.wisc.edu noquery nomodify
restrict ntp3.cs.wisc.edu noquery nomodify
restrict ntp3.sf-bay.org noquery nomodify

# NTP drift file - used to keep track of your system clocks
# time deviation
driftfile /etc/ntp.drift

# NTP log file
logfile /var/log/ntp.log

Take note that this is for a client and a server ntp.conf configuration. If you just want to synchronize with a stratum server and are not concerned with other PCs synchronizing with your ntp server, then you can do something like the following (note that only 127.0.0.1 is allowed to be synchronized):

# default restrictions
restrict default noquery notrust nomodify

# Permit all access over the loopback interface
restrict 127.0.0.1

# public NTP servers to sync with (all stratum 2)
server ntp1.cs.wisc.edu
server ntp3.cs.wisc.edu
server ntp3.sf-bay.org

restrict ntp1.cs.wisc.edu noquery nomodify
restrict ntp3.cs.wisc.edu noquery nomodify
restrict ntp3.sf-bay.org noquery nomodify

# NTP drift file - used to keep track of your system clocks
# time deviation
driftfile /etc/ntp.drift

# NTP log file
logfile /var/log/ntp.log

... or if you do not care about restrictions at all, something like this (note there are no restrictions, thus no need to reduce restrictions for 127.0.0.1 to allow your local clock to synchronize):

# public NTP servers to sync with (all stratum 2)
server ntp1.cs.wisc.edu
server ntp3.cs.wisc.edu
server ntp3.sf-bay.org

# NTP drift file - used to keep track of your system clocks
# time deviation
driftfile /etc/ntp.drift

# NTP log file
logfile /var/log/ntp.log

The reason for the 'restrict' lines is security: If you do not want a secure NTP server, do not add any restrict lines to your ntp.conf file. If you want a secure NTP server, start out by adding a default restrict that does not allow anything to contact your server, then add more (less restrictive) restrict lines - allowing certain addresses various access privileges.

Making ntpd keep the servers in the list while network is still down

During startup ntpd may start before you have a usable network connection. In this case ntpd will try to resolve the names of the servers and it will fail and remove all servers from the list of usable servers. To avoid this you may want to add the addresses of the ntp servers you will be using to the /etc/hosts file. What you need to add to the /etc/hosts file looks like:

128.105.39.11 ntp1.cs.wisc.edu
128.105.37.11 ntp3.cs.wisc.edu
206.55.70.42 ntp3.sf-bay.org

You can find the IP address of the servers you want to use with:

nslookup ntp1.cs.wisc.edu

/etc/rc.d/network

One more thing that you may want to do. In some cases, your /etc/ntp.conf file may be overwritten by dhcp. To avoid this, edit the /etc/conf.d/dhcpcd file and add -N to the line that starts with 'dhcpcd -t 10'.

On the system, /etc/conf.d/dhcpcd contains a single line:

DHCPCD_ARGS="-t 30 -h $HOSTNAME"

Change it to:

DHCPCD_ARGS="-N -t 30 -h $HOSTNAME"

Some have suggested adding -R to preserve /etc/resolv.conf as well.

Note: This step is unnecessary with the dhcpcd currently provided in Core (It doesn't even have a "-N" option).

/etc/conf.d/ntp-client.conf

This is for /etc/rc.d/ntpdate configuration. Edit NTP_CLIENT_SERVER for your ntp server.

# change this to a server closer to your location
NTP_CLIENT_SERVER="pool.ntp.org"

# client options
NTP_CLIENT_OPTION="-b -u"

# timeout for the ntp-client
NTPCLIENT_TIMEOUT=10

# arguments passed to ntpd when started
NTPD_ARGS="-g"

/etc/rc.conf

Disable HARDWARECLOCK to avoid interfering with ntpd. It is done by setting it to something else than "UTC" or "localtime":

HARDWARECLOCK="ntp"
Note: HARDWARECLOCK control the setting of an hourly cron-job that adjust the time, causing ntp to go out of sync. You may want to disable the cron-job too.

Add ntpdate and ntpd to the DAEMONS array:

DAEMONS=(syslog-ng network ntpdate ntpd ...)
Note: ntpdate has to be placed before ntpd and never be prefixed with "@" (ntpdate has to be run and finished by starting ntpd). Because the both processes use same NTP port))

Updating immediately using ntpdate

It is recommended to add a line like the following to your /etc/rc.local file so when you boot your system, your time will be correct (use an NTP server close to your location).

/usr/bin/ntpdate ntp1.cs.wisc.edu

Running ntpdate when you boot up is a good idea because ntpd may take a long time to synchronize your local clock depending on how far off the time is. If your clock is synchronized when ntpd starts, then its sole purpose is to keep it synchronized. To run ntpd at startup, add ntpd to the daemons section of the /etc/rc.conf file.

ntpd will work well if you have a connection to the internet all the time. If you are using dialup, you may just want to stick with using ntpdate via the command line.

Using NetworkManager dispatcher

With NetworkManager dispatcher scripts it is possible to update the time right after it has connected successfully. For this you need to place the following script to /etc/NetworkManager/dispatcher.d/time-sync and make it executable (e.g. chmod +x time-sync).

#!/bin/sh

case "$2" in
  up)
    ntpdate pool.ntp.org &>/dev/null
    ;;
  *)
    echo "usage: $0 {up}"  
esac
exit 0

Querying a NTP server using ntpq

There is a default restrict statement for the localhost that includes an ignore flag. Without overriding it (adding the line restrict 127.0.0.1) you will not be able to query your NTP server. If that is not a concern to you, then leave out the restrict line for your localhost. You will still be able to synchronize with your stratum 2 servers.

External links