[ntp:questions] ntpd just not working

Steve Kostecke kostecke at ntp.org
Wed Oct 10 15:08:48 UTC 2007


On 2007-10-10, David Woolley <david at ex.djwhome.demon.co.uk.invalid>
wrote:

> In article <slrnfgntnb.cbp.kostecke at stasis.kostecke.net>, Steve
> Kostecke <kostecke at ntp.org> wrote:
>
>> On 2007-10-07, David Woolley <david at ex.djwhome.demon.co.uk.invalid>
>> wrote:
>
>> > A leaf node needs one, basic, server line and nothing else.
>
>> Without a drift file line ntpd has no way of saving it's learned
>> clock
>
> The point I was making is that getting a working ntp configuration is
> very easy. Everything else is optional.

Your sentence is an assertion about the configuration needed for a leaf
node, not a description of the basic configuration needed to make ntpd
work.

> Once you start adding back options, you introduce more things that can
> go wrong, e.g. there may be file permissions on the drift file;

Incorrect permissions merely prevent ntpd from writing or updating the
drift file. They will not prevent ntpd from working.

> many people may think that restricting ntpd to minimise allowed
> protocol interactions is essential,

A knee-jerk reaction caused by insufficient documentation of ntpd's
default configuration and the subsequent misunderstanding of same.

> so, following your precedent, might also follow up my article
> saying you should have restricts,

Restrictions are not generally neccessary.

> but the resulting over zealous restrict lines are one of the most
> common causes of failed newbie installations, especially with
> multi-homed servers.

A knee-jerk reaction caused by insufficient documentation of ntpd's
default configuration and the subsequent misunderstanding of same.

> People seem to think that you need lots of lines and options in the
> configuration file before it will even work, but usually the problem
> is that they have too many.

People in this newsgroup to think that a slash-and-burn approach to
trouble shooting is acceptable. An experienced user will be able to
review a configuration and effectively diagnose any problems with it
(e.g. discern whether or not restrictions are a problem). Similarly, an
experienced user will understand what the question mark on the dashboard
means.

> If you add the options in one at a time, after you have a working
> system, you can tell exactly what breaks the system, and for some,
> non-security, options, whether they actually give an benefit.

Modulo the fact the some configuration options fail silently rather than
breaking ntpd.

-- 
Steve Kostecke <kostecke at ntp.org>
NTP Public Services Project - http://support.ntp.org/




More information about the questions mailing list