[ntp:questions] Re: NTP, Unix and the 34-year itch (better read this)

Marc Brett marc at fordson.demon.co.uk
Mon Jan 26 18:04:22 UTC 2004


On Mon, 26 Jan 2004 09:50:15 +0100, Terje Mathisen
<terje.mathisen at hda.hydro.com> wrote:

>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

Why does it have to be automatic?  If it is done by hand more than
once every 17 years, wouldn't that be enough?  In practice it wouldn't
be very onerous to do it once or twice a year.

Marc



More information about the questions mailing list