I have a small LAN (originally using a mixture of Red Hat Linux and Fedora Core Linux, now using multiple computers all running Fedora Core 4 Linux) which periodically connects to the internet over dial-up access. This means my computers suffer from a few problems:
The obvious solution was to set up a server computer to sync itself whenever possible, and for it to act as the time server for the rest of the network (a technique recommended on http://www.pool.ntp.org/). To achieve this, I only had to do a few simple things (though the supplied documentation for NTP smothered that information with a mass of other stuff):
Ensure a server computer was using NTP to keep its clock running in sync with an accurate time source (this seems to be the default configuration, anyway).
Configure the server PC to allow the other local PCs to use it. This involved adding one line to the “/etc/ntp.conf” file:
restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify
notrap
My LAN is using local IP addresses 192.168.1.1–192.168.1.253. The network addresses and mask are to suit it, yours may be different.
You may need to remove the “notrust” keyword, it's meaning has changed over different versions of NTP. I no-longer include the keyword on Fedora Core 4 Linux (originally I was using Red Hat 9.0 Linux on the machine acting as the server).
Fudge your local server's local clock to a lowish stratum so that other local computers will still use it as a time source, but will resync to a better time source when they're able to.
server 127.127.1.0
fudge 127.127.1.0 stratum 9
Using a stratum of 9 means it's considered better than the computer's own time (usually stratum 16 for unsynced, often stratum 12 for stand-alone time servers), but will be considered a poor source of time compared to most other servers (usually stratums ranging from 1 to 4), and will be ignored in those cases (when better sources are available).
Configure the other local PCs time settings to use the local time server (done by adding the address for the time serving PC, and removing entries for other time servers, in their time and date setting GUIs, or directly modifying their “ntp.conf” files).
While not a perfect solution (my time serving PC isn't brilliantly accurate), it's good enough for me. And in my case, it's probably more important that my computers are in sync with each other more than being precisely in step with the rest of the world. They'll be close enough while off-line, and they'll automatically sync up when the LAN goes on-line (with the internet).
The computers will not (normally) sync to a time server that lists itself as being out-of-sync (e.g. as stratum 16). If the main server is off-line for long enough, it will lose sync, it'll declare itself to be out-of-sync (letting other clients know its status), and NTP clients may refuse to use it. The main server should eventually resync itself (when it can), and (hopefully) the other clients will automatically align with it (I haven't, yet, tested whether they temporarily ignore it, or give up on it). But in the meantime they'll maintain their clocks independently. To keep them using the main server, you'd fudge its stratum as mentioned further above.
Red Hat 9.0 Linux would automatically resync itself when it could, Fedora Core 4 Linux isn't doing this (as soon as an interface goes down, such your dial-up internet connection), it ignores it until you restart the NTP server. I resolved this annoyance by putting a restart command line into a script that's run when a PPP interface goes up:
#!/bin/bash
/sbin/service ntpd restart
This also helped with another problem: Long delays when booting the computer, because the local NTP server wanted to sync to remote ones, and couldn't. Now, I don't have the NTP server configured to start at bootup, it's started after the first PPP connection is made to the internet. Then, when it's off-line, later on, it free-wheels on a local clock until it can sync up to a real time source, again.
Red Hat & Fedora Core Linux use “/etc/ntp/step-tickers” and “/etc/ntp/timeservers” files along with the “/etc/ntp.conf” file. You'll need to remove time server addresses from them that don't match what you've got in your “/etc/ntp.conf” file (as they'll override what's set in it). You can probably just delete those files and let the system recreate them, as needed.
NB: Deleting them seems to work fine (for me), and the system hasn't recreated them. I alsto tried creating empty files for it to repopulate, but it's not used them, so far (after running for some time, and several restarts).
If you use the time and date setting GUI to configure a PC to use NTP and it cannot connect to a suitable server, it may disable the function (the server may refuse to stay running, or unset what makes it start automatically). Once successfully set to use an NTP server it will stay running, even if the server is temporarily unavailable. (Red Hat Linux behaved this way for me.)
Normally NTP will not correct a clock that's radically out of sync. You'll have to manually set its clock close to real time, then leave NTP to fine-tune it.
restrict default nomodify notrap noquery
restrict 127.0.0.1
# -- CLIENT NETWORK -------
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
# --- OUR TIMESERVERS -----
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 127.127.1.0
# --- NTP MULTICASTCLIENT ---
# --- GENERAL CONFIGURATION ---
# Undisciplined Local Clock.
fudge 127.127.1.0 stratum 9
# Drift file.
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
# Keys file.
keys /etc/ntp/keys
By default, anything can query the server for what the time is, but no more.
The localhost (127.0.0.1) has almost no restrictions.
At least three remote servers are used for the best possibility of getting real time. Using less than three means you might have to decide between two servers that don't agree with each other, and how would you tell which was right? Hopefully, using three avoids a stalemate. Using more than three will slow things down (a bit) as they're all compared, and there isn't (at this time) a 4.pool.ntp.org set of DNS records for servers. To use more than three, you'll need to find some servers that you're allowed to use (try your own ISP).
A local server is fudged with a medium stratum value (9).
The drift file is used by the server to compensate for errors.
I suspect the system maintains the delay value itself, though all of my servers are showing the same “0.008” value.
The “keys” file is ignored on my systems, as they're not set up to use authentication. It's just there as a default setting, in case they're reconfigured to use authentication.
restrict default nomodify notrap noquery
restrict 127.0.0.1
# -- CLIENT NETWORK -------
# --- OUR TIMESERVERS -----
# 192.168.1.2 is the address for my timeserver,
# use the address of your own, instead:
server 192.168.1.2 iburst
server 127.127.1.0
# --- NTP MULTICASTCLIENT ---
# --- GENERAL CONFIGURATION ---
# Undisciplined Local Clock.
fudge 127.127.1.0 stratum 12
# Drift file.
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
# Keys file.
keys /etc/ntp/keys
This configuration uses the local time server as the only remote server, it also uses itself as a lesser quality server (stratum 12) if it can't reach the main server (so it'll keep on running, rather than abort).
For more gory details about NTP, go right to the source, and visit the NTP website. Though bear in mind that individual implementations may vary in behaviour from the default design.