On Wed, 1 Aug 2001, Luke Mewburn wrote:

> On Tue, Jul 31, 2001 at 11:57:58AM -0700, Bill Studenmund wrote:
> > Also, say there are times when ntpd NEEDS to set the date back (like say
> > there's a network outage, and the clock has drifted forward & needs to be
> > scooted back). Preventing ntpd from moving the clock back can, in such a
> > case, make it unable to do its job. So systems which need the clock set
> > right will fail.
>
> The ntpdate at boot at a lower securelevel won't solve this?

Not easily. Note that I chose a (I don't think too impossable) scenario
where on-boot fixing wouldn't be easy. The scenario is that the machine is
up, was synced, lost net connectivity, clocks drifted (something happened
where we should have changed the PLL values but didn't), we regained net
connectivity, and noticed we need to bump the date back.

ntpdate at boot would fix this, but we'd need to reboot. I don't think
that'd make our users happy.

We also could make it so that ntpd complains and tells root to come fix
the clock, and root could do an ntpdate. But then we are adding an extra
layer of sysadmin intervention.

Hmmm... I can see some sites might like the root-needs-to-fix situation,
but I think most would not. Maybe as an option..

Take care,

Bill