From: "Peter Müller" <peter.mueller@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Migrating from ntp to chrony - challenge
Date: Sat, 19 Jun 2021 08:30:31 +0200 [thread overview]
Message-ID: <62793330-9a6d-f750-867b-bbca1a121f2a@ipfire.org> (raw)
In-Reply-To: <20210618051200.GA328973@vesikko.tarvainen.info>
[-- 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
next prev parent reply other threads:[~2021-06-19 6:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3C7671DC-C106-4FDE-9194-557DD46A857C@gmail.com>
2021-06-17 21:41 ` Adolf Belka
2021-06-18 5:12 ` Tapani Tarvainen
2021-06-19 6:30 ` Peter Müller [this message]
[not found] <15235E57-D318-41EF-AD45-DA63AD839790@gmail.com>
2021-06-17 16:23 ` Michael Tremer
2021-07-06 13:08 ` Arne Fitzenreiter
2021-07-06 16:42 ` Tapani Tarvainen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=62793330-9a6d-f750-867b-bbca1a121f2a@ipfire.org \
--to=peter.mueller@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox