|
|
On Thu, 2005-11-10 at 08:08 +0100, Joachim Banzhaf wrote:
> Hi Jason,
>
> Am Mittwoch, 9. November 2005 16:39 schrieb Jason Keltz:
> > Hi Jason,
> >
> > In my case, ntp is running, but it doesn't help the situation. Let's
> > assume a machine is off when the time changes. The machine comes back
> > on, and the hardware clock is now, say, 2:00 AM when the real time is
> > say, 1:00 AM. Let's say OpenVPN starts at 2:00 AM in the boot sequence,
> > but then ntpdate runs (in our ntpd start script) and sets the clock back
> > to 1:00 AM. ntp (at least with our configuration) wouldn't have
> > touched a time that was out by an hour, and even if it would, I was
> > wondering whether the slew would cause any difficulty for OpenVPN. A
> > slew backwards slowly or making the time jump back during boot would
> > basically be the same thing, the key component being that the time would
> > be going backwards. If OpenVPN wasn't happy with time going back, it
> > wouldn't matter whether ntpdate was doing it or ntpd... It seems like
> it is not the same thing!
> ntpd is _very_ careful to change the time in so small amounts at a time, that
> no other process is able to notice (the reason why it takes sooo long until
> it reaches synced state when the difference is more than a few seconds).
More to the point, by slewing, time never goes backward. If system
time is ahead of real time (ntp time), ntpd merely slows the rate as
which time (the system clock) advances until real time catches up. But
each clock tick still advances system time forward. If system time is
behind real time, then it speeds the clock up until it catches up with
real time. In either case, time never goes backwards. It merely speeds
up or slows down until the system time and ntp time are in agreement.
You can do this manually (to adjust for very large differences in time)
by using the tickadj command. Run it without a parameter and it will
return the current "tick" increment (the amount, generally microseconds,
the system clock is incremented for each timer tick). Set it to a
larger value and time moves forward faster on a system. Set it to a
smaller value and time moves slower (but still forward). Using
different values and you can easily approach real time asymptotically to
within a second or two. I've manually slewed systems across several
hours using that technique until they were within ntp range. In those
cases, time coherency (the ability to know that one even occurred before
or after another event) was vastly more important than time accuracy and
stepping back in time would have been totally unacceptable (we won't go
into why those system were that far out to begin with :-( ).
> ntpdate however can cause arbitrary sized time jumps back and forth.
> So my advice is: _dont disable security features_ but fix your time settings.
> I think, it may be enough, to start ntpd init script with ntpdate before
> openvpn or other processes that could be confused by time jumps. At least
> that is the way I do it.
> If clients time jumps backward: their problem. They should fix that (in the
> same way as you should: jump in time _before_ it matters to someone)
> regards,
> Joachim Banzhaf
Regards,
Mike
--
Michael H. Warfield | (770) 985-6132 | mhw@xxxxxxxxxxxx
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
Attachment:
signature.asc
Description: This is a digitally signed message part
|