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_Gu... 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@ipfire.org mailto:michael.tremer@ipfire.org> wrote:

Hello,

...

On 17 Jun 2021, at 16:26, Jon Murphy <jcmurphy26@gmail.com mailto:jcmurphy26@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

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

On Tue, Jul 06, 2021 at 03:08:25PM +0200, Arne Fitzenreiter (arne_f@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