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

[Lennart Poettering]

On Tue, 26.08.14 15:44, Miroslav Lichvar (mlichvar at redhat.com) wrote:

> > 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.
> 
> Distributions usually have a full NTP client installed by default, why
> should GNOME try to enable/disable an SNTP client that happens to be
> distributed with systemd?

Well, "usually" means right *now*, little else. 

But quite frankly, we added timesyncd because we believe that installing
a full DNS server like ntpd/chrony on all client machines is absolute
overkill, but we believe that something fixing up the clock basically
needs to be installed on every system, even the most trivial ones,
embedded ones, and clients. And for all of those a minimal SNTP client
like timesyncd sounds absolutely appropriate.

If Fedora decides to install chrony/ntp by default, then that's totally
OK, but that's a Fedora decision, but it doesn't need to be something we
explicitly support with the highest possible integration in system
upstream.

> > The code wasn't wrong for what it was supposed to do. We just didn't
> > think the complexity of it would be appropriate.
> 
> Ok, this patch to make it configurable at compilation time is
> extremely simple and there is zero runtime cost, so there should be no
> problem in including it, or not?

No. We don't add configuration options for a thousand different
things. This is really not something I want to see in systemd upstream.

> > 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). 
> 
> Ok, chronyd is usually used with NetworkManager and it relies on a
> dispatcher script to get the servers from DHCP. Adding support to get
> them from networkd doesn't sound like a very difficult task if it's
> needed. Or could be networkd modified to write the list of the servers
> to a file so any NTP client could use it?

Sure, we have an C API for this already, which allows subscribing to NTP
servers coming and going, but we are not exporting that yet, since we
don't want to make any API stability guarantees yet.

> > This is really about being a *client*, and
> > not trying to outsmart servers.
> 
> Outsmart servers how exactly?

By not trusting them...

> > > 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...
> 
> Did you ask them? I think they would be ok with systemd having its own
> vendor zone, systemd is not that far to be considered a Linux
> distribution. :)

We don#t want to be a vendor, we don't want to be a product, and hence
we don't want a vendor zone. Distros need to take the responsibility for
this, not us....

If it makes you happy, then I can add a big warning to configure, if
people build things and don't specify their own NTP servers...

Lennart

-- 
Lennart Poettering, Red Hat