[systemd-devel] [PATCH] timedated: add configure option to set name of controlled NTP service

[Lennart Poettering]

On Tue, 26.08.14 11:41, Miroslav Lichvar (mlichvar at redhat.com) wrote:

> > > This is useful for installations where some other service than
> > > systemd-timesyncd is used to synchronize the system clock.
> > 
> > What's the rationale here?
> 
> To have timedated/timedatectl managing the right NTP service on
> distributions like Fedora.

I don't really think that timedated should manage an NTP server like
ntpd/chrony. timedated's primary job is to be a service to GNOME and
other DEs. But if an admin wants to upgrade to a full NTP server, then
he should really enable/disable that with "systemctl" or a similar
command.

The idea is that timesyncd is the default, and what the DEs control. But
if the admin installs any othr package, then that takes precedence.

> > We recently removed support for configuring arbitrary NTP servers from
> > timedated, see b72ddf0f4f552dd53d6404b6ddbc9f17d02b8e12. YOu patch would
> > undo this change, but in a very limited way...
> 
> Yes, it's meant to be a cheap replacement for the removed functionality.
> Perhaps I could prepare something better if I knew what exactly was
> wrong with the old code.

The code wasn't wrong for what it was supposed to do. We just didn't
think the complexity of it would be appropriate.

> > We decided to make timedated only manage timesyncd and nothing else, and
> > treat all other NTP servers as real servers that when installed and
> > enabled replace timesyncd. Hence: every other NTP server should really
> > take precedence over timesyncd, but only timesyncd is managable via
> > timedated.
> 
> The problem is timedated doesn't see or control the other NTP service.
> It may report the "NTP enabled" status incorrectly and "set-ntp false"
> may not actually disable NTP. Enabling NTP starts timesyncd, but after
> reboot there is the other NTP service running again. This is
> confusing.

Well, if admins installed a full NTP server, then they should control it
with "systemctl enable" and "systemctl disable", and it should take
precedence, but "timedatectl" is really not supposed to be that.

> > This sounds like the right thing to do, after all timesyncd
> > is really the simplest option to run for clients, and hence really is
> > what should be managed by GNOME.
> 
> I think GNOME should be managing the NTP service which is normally
> used on the system, i.e. chronyd on Fedora.

I disagree. GNOME is client software, timesyncd is client
software, and not more. I am really not convinced that GNOME should be a
frontend for a full NTP server suite.

> If your suggestion is to use timesyncd by default on all systems
> where systemd is included, that might not work. Even if you don't care
> much about accuracy, stability or monotonicity of the system clock,

I don't see why timesyncd would be any different regarding monotonicity
that chrony would...

> there is a problem with reliability. As timesyncd currently implements
> only SNTP and not full NTP client, it doesn't compare times from
> multiple servers, so it can't know when a server is broken and another
> should be selected instead.

Well, if we start comparing features, then there's also some stuff that
timesyncd can do that chrony can't (such as getting NTP server info from
DHCP networkd, or support for offline clock monotonicity of RTC-less
systems). But it isn't really about that. It's really just about
whether "timedatectl" should manage arbitrary NTP serves, or just the
one minimal SNTP client that we provide.

> When the client is configured to use just one trusted NTP server,
> that's ok. However, when public servers are used, a full NTP client is
> preferred to avoid tracking a server whose clock is completely off or
> is too slow/fast and is being periodically reset.

Well, I don't see why a Linux client should implement a full NTP server
if no other OS does that... This is really about being a *client*, and
not trying to outsmart servers.
> 
> BTW, is there an agreement with Google on using their NTP servers?

Well, but the pool.ntp.org site makes clear that there's no way we can
use theirs, Google at least doesn't do that, so we default to that.

The idea is actually that at configure time the distros specify which
NTP server to use by default, and use their distro-specific vendor
zone from pool.ntp.org. However I simply forgot adding that to the
configure line in the fedora package so far (note that timesyncd is very
recent addition). Or in other words: nobody should really use google's
servers in the distros. They should use their own pools.

> You may want to consider getting a vendor zone for systemd at
> pool.ntp.org and use it in the default list instead (after making sure
> there are no problems with frequent polling, etc.).

we are not a vendor, as we don't really do products. Vendors may use
systemd to build a product, but in that case they should use
--with-ntp-servers= and set their own NTP servers of choice...

Lennart

-- 
Lennart Poettering, Red Hat