On Mon, Jun 4, 2012 at 5:51 PM, Nate Duehr denverpilot@me.com wrote:
The reason no one ever did it "in the old days" was for fear of an NTP server going out of whack. ntpdate should be used sparingly and with knowledge that one is doing it... automating it is usually a bad idea. (Especially by default.) As I said in the original reply, it's a nasty hack.
Historically, hardware clocks that are way off at power up have been very common. It might better on current devices.
IMHO, ntpdate package install should be just to get the tool installed, no automation. If it's installing automated setting by default, that's not right. One should have to turn ON automated ntpdate at startup/shutdown after understanding the risk.
There's not too much risk from a big time jump at startup before most of your applications are doing anything. That seems much safer than waiting with a time difference that ntp itself won't fix and would take forever with it's fractional-second jumps if it tried.
Sounds like there's been some goofy decisions made somewhere along the line for ntp and ntpdate... an NTP server can be compromised and date/time changed across an envrionment (or more likely, it can have some type of failure itself...) and the old tenets of ntp were there for a reason...
Well, yes, but the cheap clocks and batteries in PCs are there for a reason too (not necessarily a good reason...) and that's what we've had to live with. I do usually run ntp on routers and sync from the ones nearby. Ciscos at least won't act as servers unless they are fairly confident about their own sources so there's not much chance of picking up a bad starting time. And you need to specify multiple servers to cover failures.