On Sun, 30 Oct 2011, Kevin A. McGrail wrote:
another that attempts to use ntpdate to check the difference between the
clocks on spamassassin2.zones.apache.org and spamassassin.zones.apache.org
and warn if the difference gets "too great" (which is yet to be
intelligently defined).
Thanks for doing this. As for testing it, I'm hoping the time skew is a
unique situation that never repeats because I don't see a better way than you
devised.
Overall, though, theoretically Infra fixed ntpupdate on the master zone for
that box so even if they changed the time, my guess is there ntpupdate would
fix it very quickly.
Agreed. Checking for clock drift in an NTP environment is inherently kinda
silly. :)
And unfortunately, purposefully changing the time would change all the
zones on that box.
So it's not something I would want to even ask to be tested on a
production box.
Yeah, there's that, too. However, if the temporary test clock drift was 10
minutes that would be enough to test the monitor and (he says hopefully)
not materially affect the other zones - which, I point out, were affected
when the clock was skewed on its own earlier, right?
However, I don't know that your system for time skew check will work without
the zones1 running ntpd. Isn't it currently just return 0 skew because it
can't contact zones?
If there wasn't an NTP daemon available on the target host it would
explicitly say no time daemon could be contacted.
I suppose there should be a test for that situation, as one way this could
happen again is ntpd on one box or the other dies and the clocks start
drifting... I'll add a check for that.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
[email protected] FALaholic #11174 pgpk -a [email protected]
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
...the Fates notice those who buy chainsaws...
-- www.darwinawards.com
-----------------------------------------------------------------------
Tomorrow: Halloween
