[ntp:hackers] Bypassing default synchronization

tsg 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 
>>> servers.
> 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 
>>> server
>>> 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 
>>> process.
> 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 
> services.
>
>>> Or
>>> 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 
>> that
>> you have chosen is broken and is serving the time 10 years in the 
>> future.
>
> 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 
>> problems
>> 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 mailing list