Re: Migrating from ntp to chrony - challenge

Re: Migrating from ntp to chrony - challenge

[Adolf Belka]

[-- 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>
>>>
>>>
>>
>

Re: Migrating from ntp to chrony - challenge

[Tapani Tarvainen]

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

On Thu, Jun 17, 2021 at 11:41:42PM +0200, Adolf Belka (adolf.belka(a)ipfire.org) wrote:

> > 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/

Although to be fair it should be noted that NTS was only approved as a
proposed standard less than a year ago, in October 2020 (RFC 8915).

Nonetheless, autokey is definitely history now and NTS support is one
more reason to go with chrony.

And I don't see any advantages to NTP that matter in IpFire, apart
from it being there now so it takes some work to replace it.

So my vote is for moving to chrony (even though I don't see it
as super urgent).

-- 
Tapani Tarvainen

Re: Migrating from ntp to chrony - challenge

[Peter Müller]

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

Hello Jon, hello Adolf, hello Tapani, hello Michael,
hello *,

thanks for this conversation, which I just wanted to comment on some minor bits and pieces.

> 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.

This is true in general, and given this description, it might look somewhat surprising to
replace ntpd - requiring a stable internet connection - with something that can handle more
patchy, unreliable situations.

At IPFire, we seem to make pretty demanding assumptions regarding the stability of our users'
internet connection, particularly when it comes to DNS and NTP, which both unfortunately
depend on each other.

While Unbound, our DNS resolver, made some efforts to deal with temporary outages less invasive,
it is still quite easy to confuse ntpd.

Some IPFire systems run behind patchy cellular networks (developing countries come to mind,
or rural areas in Germany), or unstable cable/DSL connections. I remember some people sitting
behind satellite uplinks, and there was once someone who claimed he/she runs IPFire on a really
slow connection somewhere in Africa (Kenya?).

For those people, I guess it might give them a better user experience if IPFire could deal with
such scenarios in terms of synchronising it's clock. This is why chrony looks like a good idea,
and indeed, we do not use some of the features ntpd comes with.

Sorry for not mentioning this in the conference log. :-)

> Nonetheless, autokey is definitely history now and NTS support is one more reason to go with chrony.

Basically, yes. There are still very few NTS servers out there, which is why I personally currently
shy away from it, as I like the highly diverse NTP pool ecosystem. Let's hope thing will improve
on this end, so we can move another protocol towards being encrypted in transit.

> So my vote is for moving to chrony (even though I don't see it as super urgent).

It definitely does not have a high priority to me, too. I just need to duplicate myself a few
more times, so I can spend more than 24 hours a day on IPFire development. :-)

Thanks, and best regards,
Peter Müller

Re: Migrating from ntp to chrony - challenge

[Tapani Tarvainen]

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


On Tue, Jul 06, 2021 at 03:08:25PM +0200, Arne Fitzenreiter (arne_f(a)ipfire.org) wrote:
> 
> If you change from ntp keep in mind that we need ntpdate for the settime
> skript which is used by unbound to syncronize the time with a given IP
> address if the time is incorrect and DNS not working becasue the wrong
> time breaks DNSSec.
> This is common on system without RTC Battery.
> 
> Not sure if chrony can handle this at all.

It can, with the somewhat odd syntax

chronyd -q 'server 162.159.200.1 iburst'

That is effectively equivalent to

ntpdate 162.159.200.1

-- 
Tapani Tarvainen

Re: Migrating from ntp to chrony - challenge

[Arne Fitzenreiter]

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

If you change from ntp keep in mind that we need ntpdate for the settime
skript which is used by unbound to syncronize the time with a given IP
address if the time is incorrect and DNS not working becasue the wrong
time breaks DNSSec.
This is common on system without RTC Battery.

Not sure if chrony can handle this at all.

Arne



Am 2021-06-17 17:26, schrieb Jon Murphy:
> 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:
> 
> Screen Shot 2021-06-16 at 11.42.49 AM1738×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.
> 
> 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
> 
> Anyway, my thought is to make some changes to the current NTP service
> instead of implementing something new…
> 
> 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

Re: Migrating from ntp to chrony - challenge

[Michael Tremer]

[-- 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
> 
>