[ntp:questions] ntpdate.c unsafe buffer write
stenn at ntp.org
Sat Feb 9 23:42:48 UTC 2008
>>> In article <47ae150e$0$515$5a6aecb4 at news.aaisp.net.uk>, David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:
David> Harlan Stenn wrote:
>>>>> In article <47ad8971$0$514$5a6aecb4 at news.aaisp.net.uk>, David Woolley
>>>>> <david at ex.djwhome.demon.co.uk.invalid> writes:
David> I'm not convinced that SNTP will displace ntpdate for this purpose.
>> Why not?
David> Because ntpdate is fixed in the popular culture and, for the ordinary
David> user, SNTP doesn't offer any obvious advantages.
Well, The Plan is to remove ntpdate. So unless somebody writes a
contributed script, the fact that ntpdate (with its known bugs) is going
away and a documented set of functional equivalents will be available will
probably be all the convincing that is needed.
>> If you want to get the time set *now* and then start, regardless of how
>> well the system can maintain that time, we can do that
David> Not in Dave Mills future of ntpd, as you don't get ntpdate or SNTP.
That would be true if Dave controlled the contents of the distribution.
There is a set of required functionality out there that will be met by the
distribution I control. There may be distributions I "roll" that have
subset functionality, and Dave may choose to offer other distributions.
I see no benefit and many problems in "forcing" this issue too soon, so at
the moment it is a topic for discussion and the situation seems to be on
track right now.
This is, by no means, the most important thing we're all working on right
Getting the sntp code up to spec is far more important, IMO.
>> If you want to set the time ASAP and have stable system time before
>> starting your apps, in the usual case you are talking about 11 seconds
>> for this to happen (ntpd -g, with iburst, early in the boot sequence,
>> using ntp-wait later in the boot sequence, just before starting
>> time-critical services).
David> I suspect that only sets the time to the nearest 128ms, unless it
David> does something that ntpd doesn't normally do.
I suspect you are mistaken, and what I describe is correct.
In the case I describe, at the end of that O(11 second) period the clock is
Real Close (ie, the offset is "low enough"), the frequency drift is known
and compensated for, and ntpd is in "state 4".
Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org - be a member!
More information about the questions