|
|
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). 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 ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |