[ntp:questions] Re: NTP, Unix and the 34-year itch (better read this)
terje.mathisen at hda.hydro.com
Mon Jan 26 08:50:15 UTC 2004
Simon Lyall wrote:
> Simon Burge <simonb at wasabisystems.com> wrote:
>>Note that we already have some date info in the ntpd binary - the
>>version string from version.c. From a recent build:
>> "ntpd 4.2.0a at 1.1210-r Wed Jan 14 01:33:04 EST 2004 (1)"
>>Maybe this can somehow be used in a sanity check?
> What happens in this scenario? :
> "My system clock is a few years in the future. To fix this somebody tells
> me I should install ntpd. I download the source, compile and install it
> and then attempt to run it. However it refuses to move the date backwards.
> When I manually move the date back to close to the correct time it refuses
> to start since the system time is years earlier than it was built. "
As long as you're within a +/- 34 year window you would be OK, but
starting 100 years off would always be a problem, no matter what kind of
sanity checks we insert, right?
> I would suggest that if the date is going to be in the binary/source then
> it is updated (automatically) by the ntp team when a new version of the
> source is released.
This is better, since I presume the BitKeeper repository have to know
what time it is.
The key would be to only do this step in some trusted location, which
would work nicely for the tarballs we release, but if you want to work
directly with the BK work-in-progress versions, then you'll also need a
(semi-)working local clock on the development system.
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
More information about the questions