On 2017/10/15 03:46, ti...@openmailbox.org wrote:
> An effective fix here is to simply remove the "constraints" line
> in /etc/ntpd.conf , this way ntpd makes no attempt to make any TLS
> connection (to https://www.google.com/ which is used as constraint in
> the default /etc/ntpd.conf) and instead
On Sun, Oct 15, 2017 at 07:49:48AM BST, ti...@openmailbox.org wrote:
> > 2017-10-15 6:01 GMT+02:00 :
> >
> >> >> So to sum up, my best impression presently is that time validation
> >> >> should be disabled for TLS certificates within NTPD.
> >> > Not going to change.
> >>
> >> Ok!
> >>
> >> For a
> 2017-10-15 6:01 GMT+02:00 :
>
>> >> So to sum up, my best impression presently is that time validation
>> >> should be disabled for TLS certificates within NTPD.
>> > Not going to change.
>>
>> Ok!
>>
>> For a user to add to his installer or maybe even boot scripts, a NTPD
>> invocation that is
2017-10-15 6:01 GMT+02:00 :
> >> So to sum up, my best impression presently is that time validation
> >> should be disabled for TLS certificates within NTPD.
> > Not going to change.
>
> Ok!
>
> For a user to add to his installer or maybe even boot scripts, a NTPD
> invocation that is foolproof so
>> So to sum up, my best impression presently is that time validation
>> should be disabled for TLS certificates within NTPD.
>
> Not going to change.
Ok!
For a user to add to his installer or maybe even boot scripts, a NTPD
invocation that is foolproof so that it will succeed with sync even if
> So to sum up, my best impression presently is that time validation
> should be disabled for TLS certificates within NTPD.
Not going to change.
Hi,
On a newly installed 6.1 machine, which has its system date set to 15 September
i.e. 30 days into the past, doing "ntpd -d -s -v" (to not deamonize, to make a
time sync directly, and print out verbose output), I am told this:
/var/db/ntpd.drift is empty
ntp engine ready
const
