On Mon, Dec 15, 2014 at 03:22:19PM +0000, Robie Basak wrote:
> If -g is specified to ntpd, then it will allow any variance the first
> time it sets the time. After that, and always if -g was not specified,
> it will exit (thus stop syncing time) if the variance is greater than
> 1000 seconds. I don't see any mechanism to configure this 1000s even
> though the manpage implies to me that it is configurable.
> In Debian and Ubuntu, /etc/default/ntp sets the default parameter to
> "-g", so it looks like the time will always be fixed regardless of the
> variance when the daemon is first run.
Good, nice to know this quirk has been addressed.
> > It only makes sense to install ntpd if it will also be configured. Are we
> > going to use pool.ntp.org? This may work well enough for "simple" uses,
> > but does allow any member of pool.ntp.org to completely mess up times of
> > potentially hundreds of thousands or millions of users.
> We're already using ntp.ubuntu.com when ntpdate is installed and ntp
> is not installed (the current default). When ntp is installed manually,
> this currently switches to pool.ntp.org.
> If we make ntp default and do not seed ntpdate any more (my proposal),
> then this will change to using pool.ntp.org by default in all cases.
> According to the default ntp.conf we ship, the decision to use
> pool.ntp.org was made by the TB, and I can see your concern was
> presented at the time (in LP bug 104525). It seems to me that a decision
> on this has already been made and would remain valid if we made NTP
> default. If you disagree though, please let me know soon and we can ask
> the TB for clarification.
After this was brought up, several members of pool.ntp.org contacted
me off-list and I got a very positive impression about the governance
I still believe some companies would rather be in control of their own
time servers -- probably more should be in control of their own time than
I suspect actually are -- but by and large using pool.ntp.org should be
a vast improvement for most of our users compared against not using ntp.
> > Will it be easy enough for an organization to override the configuration
> > in each of the use cases you've described?
> I'll need to address this question separately; thank you for asking it.
> You can always override /etc/ntp.conf, but perhaps this should be
> pre-seedable or something. There's also code to handle ntp-servers via
> DHCP; I should check to see what is active under which use case.
Pre-seedable and cloud-init would go a long way.