Re: Migrating from ntp to chrony - challenge

[Adolf Belka <adolf.belka@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 5254 bytes --]

Hi Jon,

On 17/06/2021 21:05, Jon Murphy wrote:
> Here was the website I came across.  Sorry I did not reference this before...
>
> "
>
>
>       14.1.2. Choosing Between NTP Daemons
>
>  *
>     *Chrony* should be considered for all systems which are frequently suspended or otherwise intermittently disconnected and reconnected to a network. Mobile and virtual systems for example.
>  *
>     The |NTP| daemon (|ntpd|) should be considered for systems which are normally kept permanently on. Systems which are required to use broadcast or multicast |IP|, or to perform authentication of packets with the |Autokey| protocol, should consider using |ntpd|. *Chrony* only supports symmetric key authentication using a message authentication code (MAC) with MD5, SHA1 or stronger hash functions, whereas |ntpd| also supports the |Autokey| authentication protocol which can make use of the PKI system. |Autokey| is described in RFC 5906.
>
> "
> From:
> https://docs.fedoraproject.org/en-US/Fedora/24/html/System_Administrators_Guide/ch-Configuring_NTP_Using_the_chrony_Suite.html <https://docs.fedoraproject.org/en-US/Fedora/24/html/System_Administrators_Guide/ch-Configuring_NTP_Using_the_chrony_Suite.html>
>
You can also look at the chrony website

https://chrony.tuxfamily.org/index.html

https://chrony.tuxfamily.org/comparison.html

> I am guessing we don’t do autokey!
>
No we don't. See this article from 2015 about autokey and it's now 2021.

https://www.nwtime.org/network-time-security-nts-replacing-autokey/

Regards,

Adolf

> Jon
>
>> On Jun 17, 2021, at 11:23 AM, Michael Tremer <michael.tremer(a)ipfire.org <mailto:michael.tremer(a)ipfire.org>> wrote:
>>
>> Hello,
>>
>>> On 17 Jun 2021, at 16:26, Jon Murphy <jcmurphy26(a)gmail.com <mailto:jcmurphy26(a)gmail.com>> wrote:
>>>
>>> I’d like to challenge!
>>>
>>> (This post was recently moved from the IPFire Community to the Development Mailing List)
>>> I saw this in the agenda from last week:
>>>
>>> <80392284118cf74d1a1176de8762f1da431444d3_2_517x148.png>
>>> Screen Shot 2021-06-16 at 11.42.49 AM
>>> 1738×500 51.1 KB
>>>
>>>
>>> I thought chrony was more for desktops & laptops. Devices that power down and might have a big time jump. And NTP was more for servers or devices that run full-time.
>>
>> Yeah, I suppose that was true. Chrony used to be a client only, so it could not share its time with the network. That functionality was however added and it can also read from local time sources now.
>>
>> I would say that they can be used interchangeably today. Some obscure features might be missing from chrony, but it should absolutely cover our use case.
>>
>>> The current NTP in IPFire can be easily changed from polling (one per hour / once per day) to non-polling by making a few simple changes to a config file:
>>>
>>> disable
>>> monitor
>>>
>>> restrict
>>> default nomodify notrap nopeer
>>>
>>> restrict 127.0.0.1
>>> server  $NTP_ADDR_1
>>> prefer
>>>
>>> server  $NTP_ADDR_2
>>> server  127.127.1.0
>>> fudge   127.127.1.0 stratum 10
>>> driftfile
>>> /etc/ntp/drift
>>>
>>> $NTP_ADDR_1 and _2 are the Primary NTP server and Secondary NTP server from the https://ipfire:444/cgi-bin/time.cgi <https://ipfire:444/cgi-bin/time.cgi> webgui page.
>>>
>>> And by changing the https://ipfire:444/cgi-bin/time.cgi <https://ipfire:444/cgi-bin/time.cgi> Synchronization to Manually
>>
>> This would have been useful, but the change to chrony was proposed and I would like that because ntp was full of CVEs recently whereas chrony has a way more modern code base which hopefully is well reviewed and does not introduce anything bad.
>>
>>> Anyway, my thought is to make some changes to the current NTP service instead of implementing something new…
>>
>> So far this is an item that Peter put on his to-do list, but I am not sure if anything was done about it, yet.
>>
>> -Michael
>>
>>>
>>> Jon
>>>
>>> ---------------------------
>>>
>>> TL;DR
>>>
>>>
>>> When NTP is configured differently (Manually polling enabled) it will “correct” on it own:
>>>
>>> Oct  6 21:40:01 ipfire ntpdate: Updated drift file.  Drift is 0.000 PPM at Tue Oct  6 21:35:43 CDT 2020
>>> Oct  6 23:20:01 ipfire ntpdate: Updated drift file.  Drift is -18.986 PPM at Tue Oct  6 23:16:05 CDT 2020
>>> Oct  7 00:20:01 ipfire ntpdate: Updated drift file.  Drift is -140.863 PPM at Wed Oct  7 00:16:04 CDT 2020
>>> Oct  7 01:20:01 ipfire ntpdate: Updated drift file.  Drift is -210.676 PPM at Wed Oct  7 01:16:04 CDT 2020
>>> Oct  7 02:20:01 ipfire ntpdate: Updated drift file.  Drift is -347.531 PPM at Wed Oct  7 02:16:04 CDT 2020
>>> Oct  7 03:20:01 ipfire ntpdate: Updated drift file.  Drift is -407.147 PPM at Wed Oct  7 03:16:04 CDT 2020
>>> Oct  7 04:20:01 ipfire ntpdate: Updated drift file.  Drift is -414.606 PPM at Wed Oct  7 04:16:04 CDT 2020
>>> Oct  7 05:20:01 ipfire ntpdate: Updated drift file.  Drift is -414.826 PPM at Wed Oct  7 05:16:04 CDT 2020
>>>
>>> More into:
>>>
>>> https://community.ipfire.org/t/odd-ntp-offset-issues-continued/492 <https://community.ipfire.org/t/odd-ntp-offset-issues-continued/492>
>>>
>>>
>>
>