On Thu, Nov 27, 2014 at 10:00 PM, Andrew Lutomirski <luto(a)mit.edu> wrote:
On Thu, Nov 27, 2014 at 12:51 PM, Tom Gundersen <teg(a)jklm.no>
> On Wed, Nov 26, 2014 at 3:10 PM, Chris Adams <linux(a)cmadams.net> wrote:
>> Once upon a time, Tomasz Torcz <tomek(a)pipebreaker.pl> said:
>>> On Wed, Nov 26, 2014 at 08:01:37AM -0600, Chris Adams wrote:
>>> > Once upon a time, Florian Weimer <fweimer(a)redhat.com> said:
>>> > > Do we even use the DHCP NTP server assignment?
>>> > I believe it is used for chrony and ntpd, don't know about
>>> > implementation.
>>> systemd-timesyncd uses DHCP-provided NTP servers only if systemd-networkd
>>> is used as DHCP client.
>> That should be a bug (and block it from use). There's no excuse for
>> that other than "not invented here".
> There are technical reasons for this choice, not merely NIH.
And those technical reasons are?
I realize that the shell-script-fu that most DHCP clients seem to
require is a bit messy, but it does work, and it should be more than
flexible enough to plug in some systemd-timesyncd controls.
The whole model is just the wrong way around for how
networkd/timesyncd works, so this is not simply a case of "if
(!networkd) return -EINVAL".
networkd allows consumers of network information (such as NTP servers,
DNS resolvers, HTTP proxy brokers,...) to subscribe to this
information (currently only via a C API , but could just as well
have been dbus) and be notified of changes to it. Other DHCP clients
will typically instead call a bunch of hooks (with env vars set) on
every configuration change (and it is then presumably the job of the
hook to instruct the NTP client, or whatever else, to change its
So basically the systemd model is one where the consumer pulls the
information from the producer, where the traditional DHCP model the
producer pushes the information to the consumer. It follows from this
that anyone can be a consumer of any sort of information (so you can
come along and implement your alternative NTP clients hooking into
networkd just fine), but making a drop-in replacement for a producer
of information is not necessarily that straightforward (you basically
have to go out of your way to make sure you mimic all the interfaces
etc). I guess this is how our stack works most of the time anyway,
replacing things higher in the stack is always easier than replacing
things lower in the stack (because the kernel does not have hooks to
call into your browser, your browser calls into the kernel...).
Now that's just the design, you can of course make whatever bash
scripts do whatever briding in either direction to make things behave
in any way you want.
As a counterexample, I run some production servers with rather
complicated network configurations. NetworkManager is a nonstarter,
and I suspect that systemd-networkd will never work for them either.
There are certainly still usecases we don't cover, but a-priori we are
interested in making anything work, so feel free to give us ping over
at the systemd ML if we lack some features you need.
This isn't a complaint about either package -- I don't really
them to understand my configuration. I use a Python script that reads
a rather large hand-curated config file and outputs Debian
interfaces(5) rules with a liberal sprinking of "up" and "down"
I do use NTP, and I don't really care much which implementation
using, but if systemd-timesyncd refuses to be reasonably configurable
unless systemd-networkd is installed, I won't be using *that* any time
You can of course still configure systemd-timesyncd to use a set of
statically configured NTP servers, it is only the DHCP integration
that currently requires networkd. That said, timesyncd is supposed to
be this simple client that "just works" in the 99% of simple setups.
If you have something fancy going on, it may very well be that you'll
be better served by some other client (and that's just fine IMHO).
And if Fedora becomes dependent on services that aren't
My understanding is that timesyncd is meant to be a good enough
default that "just works", but not the one true NTP client. It is (or
may at least one day be) a reasonable default, but it should clearly
still be possible to exchange it with something else.