[ntp:hackers] Bypassing default synchronization
tglassey at earthlink.net
Fri Jul 19 03:58:23 UTC 2013
On 07/18/2013 08:52 PM, tsg wrote:
> On 07/18/2013 07:01 PM, Hal Murray wrote:
>> gava.c at free.fr said:
>>> If I try to be clearer : the first initialization of system clock is a
>>> particular process that shall take the max time of some other NTP
> Lets ask whether this is about policies or process - are you trying to
> say you will implement a feed process which will take a pre-detrmined
> number of ticks? or are you trying to say that you are implementing a
> policy that the initialization-event (as opposed to
> in-operating-period steering or offset-tracking events?) tracks...
>>> Each server communicate is time using broadcast for a certain amount of
>>> time, and at the end of this period, they all take the date of the
>>> which has the greater date.
> So this then has a polling loop which votes among the servers...
>>> Our idea is either : to start ntpd, and playing
>>> with commands and traps, making it following this initialization
> There are all kinds of process control services which will do this,
> and it can easily be implemented in Perl or Python as a standalone
> server so its not that hard. Especially if you use openssl and the ssh
>>> to change ntpd if we can't do with traps and commands...
> Yeah the traps (SNMP) have all the issues they have.
>>> We thought of a
>>> last idea : make a small program that uses libntp to initialize
>>> system clock
>>> following the process I mentioned before, and then start ntpd
>> I can't figure out what you are trying to do and/or why.
> he is trying to come up with a structured initialization process -the
> real issue is why. There are a number of policy-specific reasons you
> would want to do something like this inside of certain financial and
> other control processes so that control nodes which fail to
> synchronize can be taken out of the process loop... but that means
> that the trust-envelope for the content being timestamped is limited
> to the virtualized context of this single source environment.
>>> shall take the max time of some other NTP servers
>> That sounds like a bad idea. What are you going to do if some server
>> you have chosen is broken and is serving the time 10 years in the
> You are going to have an internal offset tied to that machine.
>> There is a long history of broken NTP servers.
> You mean the public ones?
>> A major fraction of the
>> complexities of the reference NTP package is heuristics to avoid
>> like that.
> Yes and this is one of the reasons that NTP is such a strong tool when
> properly used.
>>> We thought of a last idea : make a small program that uses libntp to
>>> initialize system clock following the process I mentioned before,
>>> and then
>>> start ntpd
> You means something like NTPDATE 2.0??? I agree with Harlan's
> commentary below. Its a waste of effort. There are java SNTP and Perl
> clients which work great for a non-servo controlled timing-loop based
> time setting (i.e. doing a jam set across a local network).
>> That seems unlikely to work any better than starting ntpd with the
>> appropriate command line switches.
// Standard "perasonal email" disclaimers apply
More information about the hackers