On Sat, 1 Dec 2012, Michael Lindner <[email protected]> wrote: > yep, something like that. wasn't really interested.
The interesting thing about this is that ntpd is specifically designed to avoid problems in such situations. If a server is more than about 20 minutes out then the ntpd will never sync to it, not even if there are no other servers. If the stratum 0 server in question happened to push the wrong time to stratum 1 servers then it would be an interesting situation and I'd like to know how that happened. A server getting the wrong year isn't THAT uncommon, in fact it's what you expect in the case of a power outage combined with a motherboard battery failiure and some other hardware issues. Not to mention a typo when manually setting the date (not that anyone should be manually setting a stratum 0 server). Now if you use ntpdate from a cron job then you can have issues in this regard. I run some embedded systems that use ntpdate to save system resources and because they are expected to be in full operation soon after boot (sooner than ntpd can sync), but as they reboot at least once a day there is only the risk of one day's data being lost. I also run ntpdate from Xen DomUs, but as they get the date from the Dom0 there will probably be more serious problems if the Dom0 gets the time very wrong. > On 28/11/12 09:16, hannah commodore wrote: > > On 27/11/2012, at 23:26, Michael Lindner <[email protected]> wrote: > >> There was something recently in the IT news about a problem with NTP > >> servers, someone hacked the master server or something like that. > > > > no no no. it was a stratum 0 server that rebooted and its clock reset to > > year 2000. it was sending this time out to higher stratum severs, but it > > all auto corrected itself within a few minutes. IIRC it was a navy.mil > > server -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
