Re: Migrating from ntp to chrony - challenge

[Michael Tremer <michael.tremer@ipfire.org>]

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

Hello,

> On 17 Jun 2021, at 16:26, Jon Murphy <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 webgui page.
> 
> And by changing the 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
> 
>