Re: sequence?

an ntpd config hint
2004.05.20

executive summary
  o if you have a recent ntpd, use `ntpd -g`, and be sure
    to start it before you go multiuser if you have clock
    lock security in multiuser
  o if the above does not work for you, sorry, you need to
    read on; you may want to anyway

many applications need to be run in host environments where
an accurate clock is needed.  this is why most hosts today
chime with ntp.  but,

ntpd will not work if your clock is off by a few minutes.
it quits or just sits there forever with its finger in its
ear.  so,

newer versions of ntpd have the -g parameter, which allows
for a big first step.  this obviates the use of ntpdate in
the next paragraphs.  but, this will not work if you have
told the kernel to refuse to change the time when the
system is in multiuser mode for security reasons.

at boot, before you start ntpd, you can use ntpdate to
whack your system's time from a list of friendly nearby and
very sure to be connected chimers.

if ntpdate takes a minute and thus adds to your boot time,
then something is wrong anyway; fix it.

in case your dns resolver is slow, servers are in trouble,
you're running ntpdate before dns resolution is up [0],
etc.  have an entry for your ntpdate chimer(s) in
/etc/hosts.  yes, i too hate /etc/hosts; but i have been
bitten without this hack; named is even more fragile than
ntpd.

run ntpdate -b with a list of servers.  this will help if
one or more are unreachable.

once ntpdate has run, then and only then, start your ntpd.
and read all the usual advice on configuration, selection
and solicitation of chimers with which to peer, ...

the 'iburst' keyword for servers listed in ntp.conf will
cause ntpd toperform an initial sync (defined as any
synchronization after a transition out of an unsynchronized
state) with a short burst of packets in a small interval.
so, you get a faster clock update for a small tradeoff in
accuracy.  not considered polite to public servers, but if
you have local boxes that keep pretty good time, it's may
be worth the minute amount of extra traffic.

and then, if having accurate time on this host is critical,
cron a script which runs `ntpq -p` and pipes it to a hack
which looks to be sure that one of the chimers has a splat
in front of it.  run this script hourly, and scream bloody
hell via email if it finds problems.

for more info, see <http://twiki.ntp.org/>.

Thanks to
  Rob Foehl
  Brad Knowles
  Peter Lothberg
  Kevin Oberman
  Saku Ytti

---

[0] - if dnssec is deployed, somewhat accurate time will be
      needed before name resolution will work.  so, if you
      are an optimimst, expect to see ntpd up before named
      more and more in the future

-30-